home Главная chevron_right Блог и статьи chevron_right Как ускорить каталог на 1С-Битрикс: методология — фасетные индексы, Redis-кэш и репликация MySQL

Как ускорить каталог на 1С-Битрикс: методология — фасетные индексы, Redis-кэш и репликация MySQL

Пошаговая методология: как найти узкие места каталога на 1С-Битрикс, перестроить фасетные индексы, разгрузить MySQL через master-slave репликацию и настроить композитный кэш под пиковые нагрузки.

SK Pro Lab
Команда SK Pro Lab Инженерная база знаний
• 17 сентября 2026 • schedule 8 мин чтения

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

1. Диагностика: сначала замеры, потом действия

Оптимизация «на глаз» — потраченный бюджет. Прежде чем что-то менять, зафиксируйте базовые метрики: время ответа страниц категорий (Nginx access log с $request_time и $upstream_response_time), медленные SQL-запросы (slow query log MySQL) и профиль PHP (xhprof или spx на стенде). На практике чаще всего узкое место — не код: основную долю времени съедают выборки фасетного фильтра и дублирующиеся запросы свойств (N+1). Замеры покажут вашу реальную картину.

2. Фасетные индексы умного фильтра

Три правила фасетов: в умном фильтре оставляем только свойства, по которым реально фильтруют (проверяется по статистике внутреннего поиска); текстовые свойства из фасетов убираем — это главный источник тормозов; числовые диапазоны переводим в свойства-списки с разумным шагом. После каждого изменения перестраивайте фасетный индекс (Магазин → Настройки → Фасетный индекс) и сразу перемеряйте выборку фильтра.

// b_iblock_...index: следим, чтобы индекс не «расползался»
SELECT * FROM b_iblock_property WHERE IBLOCK_ID = 12 AND PROPERTY_TYPE = 'S' AND USER_TYPE IS NULL; // текстовые свойства в фасетах — главный источник тормозов

3. Redis вместо файлового кэша

На больших каталогах файловый кэш порождает множество мелких файлов и деградирует при параллельной записи. Стандартное решение — перевести кэш Битрикса на Redis с igbinary-сериализатором: плотнее упаковка, быстрее разбор, плюс под рукой статистика hit rate:

// .settings.php custom cache engine
'cache' => [   'type' => 'redis',   'redis' => [     'host' => '127.0.0.1', 'port' => 6379,     'serializer' => Redis::SERIALIZER_IGBINARY   ] ]

4. Master-slave репликация MySQL

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

5. Композитный кэш и «ленивые» блоки

Композитный сайт отдаёт статическую часть страницы мгновенно из Nginx, а динамические зоны (корзина, персональные рекомендации) подгружаются AJAX-ом. Критично правильно настроить список исключённых URL — страницы с формами и корзину в композит не включайте.

6. Как оценивать результат

Результат оценивайте по своей инфраструктуре: фиксируйте до и после каждого шага время ответа страниц категорий, время выборки фасетного фильтра, hit rate кэша и нагрузку на базу. Каждое изменение — отдельным шагом с замером: только так видно, что именно дало эффект, и только так можно принять работу у подрядчика — по отчёту «было/стало», а не по обещаниям.

Чек-лист

check_circleСократить свойства в умном фильтре, перестроить фасетный индекс
check_circleRedis + igbinary, TTL под сезонность каталога
check_circleСлейвы под чтение и под обмен с 1С
check_circleКомпозит с продуманным списком исключений
check_circleЗамеры до и после — только так, а не «на глаз»
Нужна такая же автоматизация? Разберём ваш процесс и предложим решение — бесплатно.
forum Обсудить проект

Читайте также

Ещё материалы из инженерной базы знаний SK Pro Lab


call Позвонить send Telegram calculate Рассчитать