Оптимизация высоконагруженного проекта на Битрикс

Оптимизация highload-проекта на Битрикс — это не набор случайных твиков, а последовательность измеримых шагов: сначала находим узкое место, затем устраняем его и снова замеряем. Ниже — рабочий порядок действий, который мы применяем на проектах с тысячами RPS.

С чего начинать: найти узкое место, а не гадать

Главная ошибка при оптимизации — начинать с тюнинга того, что попалось под руку. Пока вы не измерили, где именно теряется время, любая правка — лотерея. Начните с монитора производительности Битрикс (/bitrix/admin/perfmon_panel.php) и панели разработчика внизу страницы, которая показывает время генерации, число хитов кэша и количество SQL-запросов.

Типовые узкие места распределяются предсказуемо:

• База данных — тяжёлые выборки, отсутствие индексов, filesort, N+1 в компонентах каталога;
• PHP — неоптимальные компоненты без кэша, регулярные пересчёты, тяжёлые события;
• ввод-вывод — управляемый кэш на диске, логи, сессии в файлах;
• внешние вызовы — синхронные обращения к 1С, платёжным шлюзам, API поставщиков.

Оценка масштаба: BUS и базовые настройки

Прежде чем лезть в код, проверьте очевидное. Запустите тест производительности (Bitrix Universal Score) в Настройки → Производительность → Панель производительности и сверьте показатели конфигурации с рекомендуемыми. Часто половина проблем — это неверные значения в PHP и MySQL.

Отдельно убедитесь, что включён opcache с прогретым кэшем: на первом хите после деплоя генерация всегда медленнее — это норма, а не деградация.

Кэширование: главный рычаг ускорения

На Битрикс кэш даёт больше всего эффекта при минимальных рисках. Работайте по трём уровням:

1. Кэш компонентов — включайте для всех тяжёлых компонентов каталога, меню, новостей. Не забывайте про кэшируемые тегированным кэшем выборки, чтобы сброс шёл точечно.
2. Автокэширование — глобальный флаг в Настройки → Автокэширование. На проде должен быть включён всегда.
3. Композитный сайт — вынос статической части страницы в отдельный кэш и отдача её до старта ядра.

Для кастомного кода используйте \Bitrix\Main\Data\Cache и TaggedCache. Тегируйте кэш идентификаторами инфоблока (iblock_id_XX), чтобы при изменении элемента сбрасывался только связанный кэш, а не весь сайт.

База данных: индексы и тяжёлые запросы

Когда кэш выжат, узким местом почти всегда остаётся MySQL. Включите лог медленных запросов (slow_query_log) с порогом long_query_time = 0.5 и соберите топ по частоте и суммарному времени через pt-query-digest или монитор Битрикс.

Что проверять в первую очередь:

• EXPLAIN тяжёлых выборок — ищите type: ALL (full scan) и Using filesort;
• индексы на пользовательских свойствах инфоблоков и фильтруемых полях;
• размер innodb_buffer_pool_size — под данные и индексы должно хватать памяти;
• умные фильтры каталога — включённый facet-индекс резко снижает нагрузку.

Для больших каталогов переводите инфоблоки в режим Инфоблоки 2.0 — отдельные таблицы свойств вместо общей b_iblock_element_property дают кратный выигрыш на выборках.

Код и события: где утекает время

Медленный код чаще всего прячется в обработчиках событий и агентах. Проверьте:

• обработчики OnBeforeIBlockElementUpdate, OnSaleOrderSaved — синхронные обращения к внешним системам блокируют пользователя;
• агенты (CAgent), выполняющиеся на хите, — переносите на cron;
• отправку писем и уведомлений — только через очередь, не в момент запроса.

Тяжёлые операции обмена с 1С, генерацию документов и рассылки выносите в фоновые задачи. Для этого используйте очереди и cron-агенты вместо агентов на хите (define('BX_CRONTAB', true)). Пользователь не должен ждать, пока отработает интеграция.

Когда одной ноды мало: масштабирование

Если вертикальный тюнинг исчерпан, переходят к горизонтальному масштабированию через модуль cluster. Он даёт репликацию MySQL master-slave, распределение кэша, разделение веб-нод и балансировку.

Кластер оправдан, когда одна нода упирается в CPU при уже оптимизированном коде и кэше. Масштабировать неоптимизированный проект — значит платить за железо вместо исправления причины.

Итог

Оптимизация highload-проекта на Битрикс — это цикл «измерил → нашёл узкое место → устранил → перепроверил». Порядок обычно один и тот же: базовые настройки PHP и MySQL, кэш и композит, индексы и тяжёлые запросы, вынос фоновых операций из хита и только затем — кластер. Прыгать сразу к железу без диагностики бессмысленно и дорого.

Мы в B2Bsite проходим этот путь на проектах с высокой посещаемостью: находим реальные узкие места под нагрузочным тестом, приводим базу и кэш в порядок и, где нужно, разворачиваем отказоустойчивый кластер. Если проект перестаёт держать нагрузку — поможем разобрать причину и построить архитектуру, которая выдержит рост.