Битрикс под нагрузкой: что ломается в прологе, компоненте и эпилоге

Сайт на Битриксе отвечает 504, процессор сервера загружен наполовину, и ни один компонент в профилировщике не выглядит виноватым. Это обычная картина: воркеры PHP-FPM заняты не расчётами, а ожиданием сессии, записи статистики, чужого кеша или внешнего API. Ниже разобрано, что происходит с запросом в прологе, компоненте и эпилоге и в каком порядке это чаще всего ломается. Материал написан для «1С-Битрикс: Управление сайтом» 23.x–24.x на PHP 8.x; в других версиях ключи настроек могут отличаться.

Путь запроса через ядро

Если на адрес нет физического файла, веб-сервер в штатной конфигурации для Битрикса отдаёт запрос в /bitrix/urlrewrite.php. Тот находит правило комплексного компонента и подключает файл раздела. Дальше три этапа.

1. Пролог. header.php подключает prolog_before.php: поднимается ядро, открывается соединение с базой, стартует сессия, определяется пользователь, срабатывают OnPageStart и OnBeforeProlog, ядро проверяет агенты, модуль статистики фиксирует хит. Затем prolog_after.php выводит шапку шаблона.
2. Компонент. IncludeComponent() считает ключ кеша и либо отдаёт готовый результат, либо делает запросы, строит данные и подключает шаблон.
3. Эпилог. Подвал шаблона, epilog_before.php и epilog_after.php, обработчики OnEpilog и OnAfterEpilog, подстановка отложенных блоков вроде ShowHead, завершение записи статистики.

Для нагрузки важно одно: пролог и эпилог оплачивает каждый хит: страница, AJAX-вызов, ответ 404, запрос бота. Компонент оплачивает только вызвавший его хит и только при промахе кеша.

Мерить нужно не скорость компонента, а цену пустого хита: сколько воркер PHP тратит на страницу, где компонентов нет вообще.

Пролог: ломается первым

Он выполняется на каждом хите и почти целиком состоит из обращений к общим ресурсам: сессиям, базе, диску.

Сессии

При файловых сессиях PHP держит блокировку файла до конца запроса. Страница и три AJAX-вызова одного посетителя выстраиваются в очередь, а воркеров занимают четыре. Если в модуле «Проактивная защита» сессии хранятся в базе (таблица b_sec_session), к блокировке добавляется запись в БД на каждый хит. Режимы хранения задаются в /bitrix/.settings.php. Точные ключи для вашей версии ядра смотрите в документации, переписывать их по памяти не стоит.

Статистика и агенты

Модуль «Веб-аналитика» пишет в таблицы b_stat_* на каждый хит, включая ботов: это постоянный поток записей в одни и те же таблицы. Если посещаемость вы смотрите в Яндекс Метрике, модуль стоит отключить.

Агенты по умолчанию выполняются на хитах посетителей: кому не повезло, тот платит временем ответа за чужую фоновую задачу. Перенос на cron описан в документации: константа BX_CRONTAB_SUPPORT в dbconn.php и запуск cron_events.php по расписанию. Детали сверьте с разделом об агентах для вашей версии.

Лёгкий AJAX-обработчик

Для служебных вызовов статистику и агенты можно отключить константами, объявив их до подключения пролога. Пример для Битрикса 23.x–24.x, PHP 8.x. Это заглушка без проверки прав, свою проверку добавьте сами.

<?php
// Лёгкий AJAX-обработчик. Константы объявляются до подключения пролога
define('NO_KEEP_STATISTIC', true); // не писать хит в статистику
define('NO_AGENT_CHECK', true);    // не запускать агенты на этом хите

require $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php';

header('Content-Type: application/json; charset=UTF-8');
echo json_encode(['status' => 'ok']);

require $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/epilog_after.php';

Пролог всё равно выполнится, и сессия стартует. Это сокращение пути, а не его отмена.

Компонент: кеш решает не всё

Промах кеша

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

Кеш-штамп (cache stampede, dogpile) — лавина одновременных перестроений одного и того же кеша после его истечения или сброса.

Файловый кеш

По умолчанию кеш лежит файлами в /bitrix/cache: много мелких файлов и нагрузка на диск. На нескольких веб-серверах у каждого свой кеш, и сброс на одном не затрагивает остальные. Хранилище кеша выносят в memcached или Redis, это тоже настройка .settings.php.

Запросы к инфоблокам

Фильтр по свойствам в старом хранении (общая таблица b_iblock_element_property) требует JOIN на каждое свойство. Хранение версии 2 выносит единичные свойства в отдельную таблицу инфоблока, а для умного фильтра есть фасетный индекс. Комбинаций фильтра много, кеш по ним почти не попадает, поэтому фильтр каталога чаще всего бьёт по базе напрямую.

Эпилог: хвост держит воркер

Воркер освобождается только после эпилога. Всё, что повешено на OnEpilog и OnAfterEpilog, продлевает его занятость. Сторонние модули любят класть туда логирование, отправку в CRM, запросы к внешним API. Один медленный внешний сервис, и пул воркеров исчерпан: Nginx отвечает 502 или 504 при нормальном процессоре. Такие вызовы выносят в очередь или в агент на cron.

Что ломается и в каком порядке

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

Как мерить

• Пустой хит: тестовая страница с минимальным шаблоном без компонентов. Нагрузите её через k6, wrk или ab на стенде, равном проду, и зафиксируйте RPS и p95. Это нижняя граница цены пролога и эпилога.
• Затем включайте по одному: статистику, агенты, компонент с кешем и без. Разница между замерами и есть цена каждого этапа. Записывайте версию ядра, PHP, число воркеров, тип хранилища сессий и кеша, объём каталога, параллельность.
• На проде смотрите статус пула PHP-FPM (активные процессы, счётчик max children reached), slow log FPM и slow query log MySQL. Тяжёлые запросы страниц показывает модуль «Монитор производительности».

Готовых цифр здесь нет намеренно: они зависят от железа, шаблона и набора модулей.

Где подход ломается

• Композитный сайт отдаёт анонимам готовый HTML, но динамические зоны догружаются AJAX-запросами, и каждый проходит полный пролог. Корзину и личный кабинет он не закрывает.
• Агенты на cron: долгий агент теперь блокирует очередь задач, а не хит. Запускайте cron от того же пользователя, что и веб-сервер, иначе в /bitrix/cache появятся файлы с чужими правами.
• Сессии и кеш в Redis или memcached: хранилище становится точкой отказа. Продумайте поведение сайта, когда оно недоступно.
• Отключение статистики: проверьте, что на её данные не завязаны другие модули.

Что делать дальше

1. Снимите цену пустого хита и запишите её как базовую линию.
2. Проверьте в .settings.php, где лежат сессии и кеш.
3. Отключите статистику, если она не нужна, и перенесите агенты на cron, сначала на тестовой копии.
4. Включите slow log PHP-FPM и найдите пять самых долгих стеков.
5. На проде следите за долей занятых воркеров и счётчиком max children reached.

Настройка Nginx и пулов PHP-FPM, а также сброс кеша при импорте из 1С — отдельные темы, здесь они не разбираются.