Скидки тормозят сайт: решение проблем производительности

Скидки — одна из самых частых причин медленного каталога и корзины в 1С-Битрикс. Каждое правило работы с корзиной и каждая скидка каталога участвуют в пересчёте цены, а на большом ассортименте и десятках акций это выливается в лишние запросы к базе и секунды ожидания. Разберём, где именно теряется скорость и какими штатными средствами её вернуть.

Почему скидки нагружают сайт

Скидки в 1С-Битрикс — это не статичная надпись на цене, а вычисление, которое выполняется при каждом расчёте. Есть два принципиально разных механизма, и тормозят они по-разному.

• Скидки каталога применяются к цене товара в списках и карточках. Чтобы вывести цену со скидкой, система должна для каждого товара определить, какие скидки на него распространяются, — а это перебор условий по разделам, брендам и свойствам.
• Правила работы с корзиной (модуль sale) пересчитываются при каждом изменении корзины и оформлении заказа. Битрикс генерирует из дерева условий исполняемый PHP-код и прогоняет его по всему составу заказа.

Пока правил и товаров немного, нагрузка незаметна. Проблемы начинаются, когда в каталоге десятки тысяч позиций, а активных скидок и правил — десятки. Тогда на каждый вывод списка и каждый пересчёт корзины приходятся сотни лишних операций.

Как найти узкое место

Прежде чем оптимизировать, нужно убедиться, что тормозят именно скидки, а не шаблон или сторонний модуль. Помогают штатные инструменты платформы:

• Монитор производительности (модуль perfmon) — раздел Настройки → Производительность → Монитор производительности. Он показывает время выполнения хитов, самые долгие SQL-запросы и разбивку по компонентам.
• Отладка запросов — на странице каталога включите вывод статистики и посмотрите, не всплывают ли повторяющиеся запросы к таблицам b_catalog_discount и b_sale_discount.
• Панель разработчика компонентов показывает время рендеринга catalog.section и sale.basket.basket — если время резко растёт при включённых акциях, причина в скидках.

Практический признак: страница списка товаров работает быстро с пустым каталогом скидок и заметно медленнее — когда акции включены. Это прямое указание на расчёт скидок как узкое место.

Индекс скидок каталога

Ключевой инструмент ускорения скидок каталога — индекс скидок. Вместо того чтобы при каждом выводе товара заново вычислять применимые акции, Битрикс заранее строит таблицу соответствия «товар → скидка» (b_catalog_discount2product) и при показе цены обращается уже к готовому индексу.

Управляется он в настройках модуля Торговый каталог: Настройки → Настройки продукта → Настройки модулей → Торговый каталог. После создания или изменения скидок каталога индекс нужно переиндексировать — вручную по кнопке в списке скидок или фоновым агентом. Пока переиндексация не выполнена, новые скидки могут либо не применяться, либо считаться «на лету» с полной нагрузкой.

Кэширование правил корзины

Правила работы с корзиной каждый раз собираются из базы и компилируются в PHP. Чтобы не повторять это на каждом хите, в настройках модуля Интернет-магазин (/bitrix/admin/settings.php?mid=sale) включается кэширование правил. Тогда скомпилированный набор условий и действий берётся из кэша, а не пересобирается заново.

Ещё один параметр, влияющий на скорость, — дискретный расчёт скидок. Он пересчитывает скидки пошагово, отдельными «порциями», и повышает точность в сложных сценариях, но ощутимо увеличивает нагрузку. Если такие сценарии не нужны, дискретный расчёт лучше отключить.

• Проверьте, что кэширование правил корзины включено;
• Отключите дискретный расчёт, если не используете вложенные пошаговые механики;
• Убедитесь, что тип кэша сайта — не «файлы» на медленном диске, а memcached или другой быстрый бэкенд.

Оптимизация самих правил

Часто проблема не в платформе, а в том, как настроены акции. Несколько приёмов, которые снижают стоимость пересчёта:

Каждое активное правило участвует в пересчёте, даже если по условиям не срабатывает, — потому что систему всё равно приходится проверять условие. Поэтому число активных правил напрямую влияет на скорость корзины. Регулярная чистка неактуальных акций — самый дешёвый способ ускорения.

Кэш и инфраструктура

Расчёт скидок опирается на общий стек кэширования, поэтому его настройка тоже важна:

• Управляемый кэш и тегированный кэш — при изменении скидки сбрасываются только связанные страницы, а не весь кэш. Убедитесь, что тегированный кэш включён в настройках главного модуля.
• Композитный кэш ускоряет отдачу каталога, но персональные цены и корзина в композит не попадают — их всё равно считает PHP, поэтому индекс и кэш правил остаются обязательными.
• Быстрый бэкенд кэша — memcached или Redis вместо файлового кэша на нагруженном магазине радикально снижают время доступа к скомпилированным правилам.
• База данных — таблицы b_sale_discount и b_catalog_discount2product должны обслуживаться: следите за размером индекса и не допускайте распухания от тысяч устаревших записей.

Короткий чек-лист

Если магазин тормозит и вы подозреваете скидки, пройдитесь по шагам по порядку:

1. Замерьте время каталога и корзины через Монитор производительности, зафиксируйте базу.
2. Проверьте, включён и переиндексирован ли индекс скидок каталога.
3. Включите кэширование правил корзины и отключите дискретный расчёт, если он не нужен.
4. Сократите число активных правил: объедините похожие, удалите просроченные.
5. Упорядочьте условия внутри правил — дешёвые проверки первыми.
6. Переведите кэш на memcached/Redis и включите тегированный кэш.
7. Повторно замерьте показатели и сравните с исходными.

Такой порядок отсекает самые дорогие проблемы первыми и позволяет увидеть эффект каждого шага отдельно.

Итог

Скидки замедляют 1С-Битрикс не сами по себе, а из-за пересчёта: скидки каталога перебирают условия по каждому товару, а правила корзины компилируются и прогоняются на каждом хите. Лечится это предсказуемым набором мер — индекс скидок каталога, кэширование правил, отключение лишнего дискретного расчёта, чистка и объединение акций, быстрый бэкенд кэша. Диагностику всегда начинают с Монитора производительности, чтобы менять настройки по фактам, а не наугад.

Если акций много, они конфликтуют между собой и заметно тормозят каталог под нагрузкой, мы помогаем найти узкое место, перестроить логику скидок и разогнать магазин — от индекса и кэша до профилирования запросов и настройки инфраструктуры.