Монитор производительности Битрикс: как читать отчёт

«Сайт тормозит» — жалоба, с которой невозможно работать. Тормозит где: на главной или в каталоге? Из-за базы, кода или сервера? Монитор производительности отвечает на эти вопросы цифрами вместо ощущений.

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

Где находится

Раздел Настройки → Производительность. Инструмент состоит из нескольких частей:

Раздел	Что показывает
Панель производительности	Сводная оценка и основные показатели
Разработчику	Детализация по страницам и компонентам
Тестирование	Скорость сервера: процессор, диск, база
Настройка кеширования	Рекомендации по параметрам кеша

Замер запускается на определённый период — например, на час. Всё это время система собирает данные о запросах, поэтому сайт будет работать медленнее. На боевом проекте замер делают в часы низкой посещаемости.

Ключевые показатели

Время генерации страницы

Главная цифра. Ориентиры для сайта на Битрикс:

Время	Оценка
До 0,3 сек	Отлично
0,3–0,7 сек	Нормально
0,7–1,5 сек	Есть над чем работать
Больше 1,5 сек	Проблема, заметная посетителям

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

Количество запросов к базе

Второй по важности показатель. Нормальная страница делает несколько десятков запросов. Несколько сотен — почти наверняка запрос внутри цикла.

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

Время выполнения запросов

Показывает, сколько из общего времени ушло на базу. Если большая часть — проблема в запросах, а не в коде.

Нужна помощь с Битрикс?

Отчёт для разработчика

Самая полезная часть. Он показывает, какие компоненты на странице сколько времени занимают и сколько запросов делают.

Типичная картина на проблемной странице каталога:

catalog.section         1.8 сек    240 запросов
catalog.smart.filter    0.9 сек    180 запросов
breadcrumb              0.02 сек   2 запроса
menu                    0.01 сек   1 запрос

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

Что делать с результатами

Много запросов на странице

ищите выборки внутри циклов;
проверьте, что в select перечислены только нужные поля;
убедитесь, что кеширование компонентов включено.

Долгие запросы к базе

включите лог медленных запросов и посмотрите на конкретные конструкции;
проверьте наличие индексов на полях фильтрации;
для умного фильтра включите фасетный индекс — об этом статья Фасетный индекс в Битрикс.

Кеш не помогает

проверьте, что тип кеширования у компонентов — «Авто», а не «Не кешировать»;
убедитесь, что кеш не сбрасывается слишком часто;
рассмотрите перенос кеша в память вместо файлов;
для страниц с одинаковым содержимым включите композитный режим.

Общие настройки разобраны в материале Настройка кеширования в Битрикс.

Медленный сам сервер

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

В этом случае вопрос переходит в плоскость ресурсов — см. статью VPS для Битрикс: настройка сервера с нуля.

Порядок работы

Запустите замер на час в обычное время работы сайта.
Найдите самые медленные страницы в отчёте.
Откройте детализацию по одной из них.
Определите виновника — компонент, дающий основное время.
Исправьте одну вещь.
Повторите замер и сравните.
Переходите к следующей проблеме.

Пятый пункт принципиален. Меняя пять вещей сразу, вы не узнаете, какая помогла, а какая ухудшила ситуацию.

Что монитор не покажет

Инструмент измеряет только серверную часть — время до отдачи HTML. За её пределами остаётся многое:

загрузка изображений, стилей и скриптов;
работа JavaScript в браузере;
сторонние счётчики и виджеты;
скорость канала до посетителя.

Поэтому монитор дополняют внешними инструментами замера скорости — подход описан в статье Как ускорить сайт на Битрикс для PageSpeed Insights. Бывает, что сервер отдаёт страницу за 0,2 секунды, а посетитель ждёт восемь — всё время уходит на фронтенд.

Частые ошибки

Замер оставили включённым. Сайт постоянно работает медленнее, а данные копятся без пользы.
Смотрят только среднее время. Проблемные страницы теряются в общей массе.
Оптимизируют быстрые компоненты. Время тратится на то, что не влияет на результат.
Меняют всё сразу. Понять, что сработало, невозможно.
Нет замера «до». Не с чем сравнивать результат работы.
Оптимизируют бэкенд при фронтенд-проблеме. Сервер уже быстрый, а тормозят скрипты в браузере.

Итог

Монитор производительности превращает «сайт тормозит» в конкретные цифры: время генерации по страницам, число запросов к базе и вклад каждого компонента.

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