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

Монитор производительности 1С-Битрикс и отладка запросов

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

Как это работает

У модуля две части. Первая - настройки: что журналировать (предупреждения PHP, кеширование, SQL-запросы, стек вызовов). Журналы пишутся в базу, и сбор идёт только при включённом мониторе. Вторая часть

  • раздел отчётов, где собранное разбирают.

Ключевые отчёты.

  • Панель производительности даёт интегральный балл - по сути число генераций пустой страницы в секунду. Абсолютное значение само по себе ничего не значит: его оценивают в контексте нагрузки и редакции продукта.
  • Конфигурация сравнивает подсистемы с эталоном и подсвечивает типичные проблемы: нет акселератора кода, статику отдаёт не тот сервер, база не на InnoDB, PHP работает как CGI.
  • Масштабируемость - встроенный нагрузочный тест.
  • Разработка - двадцать самых нагружающих страниц с разбором по компонентам: сколько запросов делает каждый и кешируется ли он. Именно здесь чаще всего и находится причина тормозов - некешированные компоненты.
  • Детальные журналы по страницам, компонентам, хитам, SQL-запросам, файлам кеша и таблицам.

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

Важное ограничение. Постоянное журналирование само нагружает систему, поэтому монитор включают на период диагностики, а не навсегда.

Примеры

1. Отладка запросов участка кода

$connection = \Bitrix\Main\Application::getConnection();
$connection->startTracker(true);   // true - собирать стек вызовов


// исследуемый код
$items = ItemTable::getList(['filter' => ['=ACTIVE' => true]])->fetchAll();


$tracker = $connection->getTracker();


echo 'Запросов: ' . $tracker->getCounter();
echo 'Время: ' . $tracker->getTime();


foreach ($tracker->getQueries() as $query) {
    echo $query->getSql();
    echo $query->getTime();
    echo $query->getTrace();
}


$connection->stopTracker();

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

Трекер умеет писать и в файл - через startFileLog().

2. Порядок поиска медленных запросов

  1. Включить в настройках модуля запись SQL-запросов и задать порог «медленного» запроса (по умолчанию 0,1 секунды). 2. Собирать статистику достаточно долго: для панели производительности хотя бы час, а для поиска медленных запросов желательно сутки. 3. Открыть анализ индексов и изучить детальный разбор конкретного медленного запроса. 4. Создать индекс прямо из детального анализа: монитор предлагает готовое выражение. 5. Проверить эффективность повторным анализом: время запроса должно заметно упасть.

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

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

Справочник

ИнструментНазначениеОсобенности
Настройки модулячто журналироватьвключать только на время диагностики
Панель производительностиинтегральный баллсравнивать только с самим собой
Конфигурациясверка с эталономподсвечивает типичные проблемы окружения
Масштабируемостьнагрузочный тестхиты в секунду, ошибки, время генерации
Разработкадвадцать нагружающих страницразбор по компонентам и кешированию
SQL-запросыжурнал запросовплан исполнения, стек вызовов
Анализ индексовподбор индексовдетальный разбор конкретного запроса
Кнопка отладкизамер на публичной страницевремя, запросы, кеш
Connection::startTracker()программная отладкааргумент включает сбор стека
Diag\SqlTrackerрезультат трекингаgetQueries, getCounter, getTime, startFileLog

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

Отчёты пустые. Не включён монитор или не включены нужные журналы. Для стека вызовов есть отдельная опция.

Не удаётся очистить собранные данные. Очистка доступна только при деактивированном мониторе.

Балл панели сравнивают между проектами. Значение зависит от редакции продукта: на одинаковом железе более старшая редакция покажет меньший балл. Это метрика для сравнения с собой до и после изменений.

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

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

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

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

С какого отчёта начинать диагностику?

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

Можно ли держать монитор включённым постоянно?

Не стоит. Журналирование запросов и особенно стека вызовов само создаёт нагрузку и растит таблицы в базе. Правильный режим - включить на период диагностики, собрать достаточную статистику (час для панели, сутки для медленных запросов), выключить и работать с собранными данными.

Как измерить количество запросов в конкретном куске кода?

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

Индексы решают проблему медленных запросов?

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

Связанные темы

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