Обработка запроса в Битрикс под нагрузкой: где узкое место

При 300 одновременных запросах сайт на Битрикс может упереться не в PHP, а в пул PHP-FPM, MySQL, файловый кеш или внешний сервис. Добавление воркеров в такой ситуации только ускорит исчерпание соединений с базой. Ниже — разбор пути запроса в 1С-Битрикс: от веб-сервера до шаблона, кеша и фоновых агентов, с признаками каждой проблемы и измерениями, которые стоит собрать до изменений.

Из чего состоит один запрос в Битрикс

Обычный динамический запрос проходит несколько слоёв. Сначала Nginx или Apache принимает соединение и передаёт PHP-скрипт в PHP-FPM. Затем Битрикс подключает ядро, определяет контекст сайта, выполняет код компонента, обращается к кешу и базе данных, формирует шаблон и возвращает ответ веб-серверу.

На каждом этапе может появиться очередь. PHP-FPM ждёт свободный процесс, процесс ждёт MySQL, MySQL ждёт диск, а код ждёт HTTP-ответ от внешнего API. Внешне всё выглядит одинаково: браузер долго ждёт страницу или получает 502. Внутренние причины при этом разные.

Термин «узкое место» означает ресурс, который первым достигает предела и начинает ограничивать всю систему. Это может быть число PHP-процессов, CPU, оперативная память, дисковые операции, соединения с базой или время ответа внешнего сервиса.

Нагрузка не делает медленный запрос быстрым. Она превращает его в очередь.

Где запрос обычно теряет время

PHP-FPM и очередь процессов

Если все процессы PHP-FPM заняты, новый запрос не выполняется сразу: он ждёт свободный процесс. При достижении лимита очереди веб-сервер может вернуть 502 или 504. Признак — высокий показатель занятых процессов PHP-FPM при не полностью загруженном CPU.

Увеличивать число процессов вслепую опасно. Каждый процесс потребляет память, а параллельные запросы создают больше соединений с MySQL и конкурируют за CPU. Рабочий предел нужно искать по фактическому потреблению памяти и времени ответа, а не по числу ядер на сервере.

Ядро, компоненты и шаблон

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

Особенно дорогими становятся страницы с динамическими фильтрами, сортировкой по полям без индексов и постраничной навигацией по большой выборке. Страница при этом может выглядеть простой, но её SQL-запросы выполняются каждый раз заново.

Кеш Битрикс

Битрикс использует несколько механизмов кеширования. В зависимости от компонента результат может храниться в файловом кеше, в Redis или другом поддерживаемом хранилище, если такая схема настроена на сервере. Отдельно существует управляемый кеш, который должен сбрасываться при изменении связанных данных.

Кеш не является бесплатным ускорителем. Слишком большой или часто инвалидируемый кеш увеличивает объём записи на диск и расход памяти. Если ключи кеша зависят от URL, пользователя, региона и набора фильтров, число вариантов быстро растёт, а доля повторного использования падает.

MySQL и ORM

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

Среднее время запроса к базе недостаточно для диагностики. Смотрите самые медленные запросы, их частоту и количество строк, которые база проверяет. Один запрос на 200 миллисекунд может быть терпимым, но тысяча таких запросов за минуту создаст отдельную очередь.

Агенты и внешние вызовы

Агенты Битрикс выполняются по расписанию или во время обработки запросов — конкретное поведение зависит от настроек проекта и способа запуска. Если тяжёлая фоновая работа выполняется внутри веб-запроса, посетитель оплачивает её ожиданием.

HTTP-вызов к CRM, платёжному шлюзу, складу или сервису доставки нельзя считать мгновенной операцией. У него есть DNS, установка соединения, ожидание ответа и тайм-аут. При недоступности внешней системы запрос может занимать секунды и удерживать PHP-процесс всё это время.

Что измерять перед изменениями

Начинайте с одного конкретного URL и одного сценария: открытие карточки товара, применение фильтра или оформление заказа. Зафиксируйте время ответа, код HTTP, размер ответа, количество запросов к базе и состояние сервера. Без этого сравнение «до и после» превращается в впечатление.

1. Время ответа. Разделите задержку на время ожидания соединения, обработку на сервере и передачу ответа. Смотрите не только среднее значение, но и p95 или p99 — время, быстрее которого укладывается 95% или 99% запросов.
2. PHP-FPM. Проверьте число активных и ожидающих процессов, достижение максимума и перезапуски из-за нехватки памяти. Если очередь растёт, ищите причину долгих запросов до увеличения пула.
3. MySQL. Соберите медленные запросы и проверьте планы выполнения. Для тяжёлых запросов важны количество проверенных строк, сортировки, временные таблицы и использование индексов.
4. Кеш. Сравните первый запрос без готового кеша и повторный запрос. Если повторный не быстрее или кеш постоянно очищается, проблема может быть в ключах, настройках хранения или частоте инвалидирования.
5. Система. Зафиксируйте CPU, RAM, swap, дисковую задержку и сетевые ошибки. Высокий load average сам по себе не объясняет причину: он может расти из-за CPU, диска или большого числа заблокированных процессов.

Для замеров используйте инструменты вашего стека: access-логи веб-сервера, статус PHP-FPM, мониторинг MySQL, профилировщик PHP и системные метрики. Названия и доступность конкретных модулей зависят от версии PHP, конфигурации хостинга и редакции Битрикс, поэтому включайте их сначала на тестовом окружении.

Как отличить одну проблему от другой

Что меняют после измерений

Если ограничение в PHP

Сначала сокращают время одного запроса: убирают повторные обращения к базе, выносят внешние вызовы из синхронного пути, ограничивают объём данных и проверяют кеш компонентов. Только после этого подбирают параметры PHP-FPM под доступную память.

Контролируйте не только число процессов, но и их фактический размер. Значения, подходящие для одного проекта, могут привести к swap на другом из-за тяжёлого каталога, большого количества модулей или различий в версии PHP.

Если ограничение в базе

Начните с конкретного SQL-запроса и его плана. Индекс должен соответствовать условиям фильтрации и сортировки, а не добавляться «на всякий случай». Лишний индекс ускоряет чтение не всегда, зато увеличивает размер таблицы и стоимость записи.

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

Если ограничение во внешнем сервисе

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

Граничные случаи и где подход ломается

Профилирование на пустой базе не показывает поведение каталога с реальным объёмом товаров. Тест с одним пользователем не показывает конкуренцию за PHP-процессы и соединения MySQL. Прогрев кеша перед тестом скрывает стоимость первого запроса, а полный сброс кеша перед каждым запуском создаёт сценарий, которого нет у обычного посетителя.

Отдельная ловушка — запускать нагрузочный тест на том же сервере, где находятся мониторинг, резервное копирование и фоновые задания. Вы получите смесь нескольких нагрузок и не поймёте, какая из них вызвала задержку.

Не делайте вывод по одному 502. Проверьте время появления ошибки, логи PHP-FPM, веб-сервера и базы данных. Если ошибка возникает только при сохранении заказа, её причины могут отличаться от проблем с каталогом, даже когда код ответа одинаковый.

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

Составьте для проекта четыре контрольных сценария: главная страница, листинг каталога, карточка товара и оформление заказа. Для каждого сохраните p95 времени ответа, долю ошибок, число SQL-запросов и загрузку PHP-FPM. Повторяйте замер после каждого изменения, а в продакшене отдельно следите за очередью PHP-FPM, медленными запросами MySQL и тайм-аутами внешних интеграций.

Материал относится к актуальным веткам 1С-Битрикс: Управление сайтом и окружению PHP, поддерживаемому вашей редакцией. Перед настройкой PHP-FPM, MySQL, кеша или агентов сверяйте совместимость с установленной версией платформы и конфигурацией хостинга: имена параметров и доступные механизмы могут различаться.