Перейти к содержимому
BXWiki

Монитор производительности - замер, отчёты, поиск узких мест

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

Механика

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

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

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

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

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

Некэшированные компоненты страниц - это главная находка данной вкладки. Именно они дают сотни запросов на страницу, и лечится это настройкой кэша, а не покупкой сервера.

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

План выполнения тяжёлого запроса открывается прямо из отчёта монитора. Там же виден стек вызовов, и по первой его строке понятно, какой код инициировал запрос.

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

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

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

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

Шаги

  1. Включить сбор данных монитора на заранее ограниченный срок для диагностики.
  2. Дать сайту поработать под обычной для него нагрузкой достаточно долгое время подряд.
  3. Посмотреть панель и отчёт конфигурации, отметить самые явные ошибки настройки.
  4. Открыть вкладку разработки и найти в ней самые тяжёлые страницы этого сайта.
  5. Разобрать компоненты этих страниц по числу запросов и по типу их кэширования.
  6. Заняться медленными запросами и только потом переходить к подбору индексов.
  7. Выключить сбор данных и повторить замер уже после внесённых правок.

Код

Смотрим статистику страницы на самом сайте:

if ($USER->IsAdmin()) {
    define('BX_SHOW_STAT', true);   // время работы и число запросов к базе
}
// панель отладки показывает то же, что отчёты, но по одной странице
// её включают только себе: посетителям эти числа не нужны

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

Трекаем запросы своего участка кода:

$connection = \Bitrix\Main\Application::getConnection();
$connection->startTracker();


$rows = \Bitrix\Iblock\ElementTable::getList([
    'select' => ['ID', 'NAME'], 'filter' => ['=IBLOCK_ID' => 12], 'limit' => 20,
])->fetchAll();


$tracker = $connection->getTracker();
$connection->stopTracker();
printf("запросов: %d\n", count($tracker->getQueries()));

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

Находим самые медленные запросы участка:

$queries = $tracker->getQueries();
usort($queries, static fn ($a, $b) => $b->getTime() <=> $a->getTime());


foreach (array_slice($queries, 0, 3) as $query) {
    printf("%.4f с: %s\n", $query->getTime(), $query->getSql());
}
// у каждого запроса доступны текст, время, стек вызовов и параметры

Три самых медленных запроса объясняют львиную долю времени страницы. Остальные обычно занимают доли миллисекунды и на общую картину не влияют.

Пишем журнал запросов в безопасное место:

$tracker->startFileLog('/var/log/bitrix/sql.log');
// журнал кладут вне каталога сайта: в текстах запросов бывают персональные данные
// каталог загрузок для этого не годится - он доступен снаружи

В текстах запросов оказываются значения фильтров, а значит телефоны и адреса. Журнал внутри сайта означает утечку этих данных всем, кто угадает имя файла.

Проверяем план выполнения тяжёлого запроса:

EXPLAIN SELECT ID, NAME FROM b_iblock_element
 WHERE IBLOCK_ID = 12 AND ACTIVE = 'Y' ORDER BY SORT LIMIT 20;
-- полный перебор таблицы в плане - повод подумать об индексе
-- но сначала стоит проверить, нужен ли сам запрос в таком виде

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

Считаем запросы страницы целиком:

// в подвале шаблона сайта, только для администратора
global $DB;
printf("<!-- запросов: %d, время: %.3f с -->",
    $DB->cntQuery, microtime(true) - $GLOBALS["BX_STATE_START_TIME"] ?? 0);
// счётчик запросов растёт по мере сборки страницы
// у закэшированной страницы запросов единицы, у некэшированной - сотни

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

Ограничения

Сам сбор данных монитора заметно нагружает работающий сайт. Постоянно включённый монитор с журналированием запросов заметно замедляет боевую площадку.

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

Интегральный балл панели не сравнивают между разными площадками и редакциями. Он зависит от редакции продукта и оборудования, поэтому смысл имеет только динамика на одном сайте.

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

Типичные проблемы

Отчёты монитора пустые.

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

Данные монитора не удаляются.

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

В отчёте нет медленных запросов, а сайт тормозит.

Порог времени задан слишком высоким или наблюдение шло слишком мало по времени. Редкий тяжёлый запрос в такую короткую выборку попросту не попадает.

После добавления индексов сайт стал медленнее на записи.

Индексы созданы механически под каждый найденный медленный запрос подряд. Каждый индекс замедляет запись, и весь их набор подбирают по общему анализу.

Журнал запросов оказался доступен снаружи.

Файл журнала запросов лежит внутри каталога сайта. В текстах запросов бывают персональные данные, и журнал держат вне корня сайта.

Частые вопросы

Как долго держать монитор включённым?

Панель - не меньше часа на малопосещаемом сайте, поиск медленных запросов - до суток. Короткое наблюдение показывает случайную картину, а не типичную.

Что смотреть в первую очередь?

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

Нужно ли создавать индексы по рекомендациям?

Только осознанно: анализ подсказывает кандидатов, а решение принимают по селективности и размеру таблицы. Индекс под каждый запрос вредит записи.

Чем трекер лучше общего отчёта?

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

Можно ли включать монитор на боевом сайте?

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

Смежное

Первоисточник