Как Bitrix считает «попугаев»: что на самом деле измеряет метрика производительности

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

Что под капотом

В административной панели Bitrix есть кнопка «Тестировать конфигурацию».

При её нажатии запускается набор тестов — от CPU и файловой системы до базы данных и сессий. Каждый тест выполняется по отдельному URL с соответствующим параметром:

url для сбора "Среднее время отклика" test=Y   url для сбора остальных параметров test=cpu test=files test=mail test=session test=php test=db_read test=ddb_update test=db_insert test=session&last=Y   Остальные параметры считаются функциями ниже и еще некоторыми другими grep 'public static function' modules/perfmon/classes/general/measure.php         public static function GetPHPCPUMark()         public static function GetPHPFilesMark()         public static function GetPHPMailMark()         public static function GetDBMark($type)         public static function GetAccelerator()         public static function GetAllAccelerators()         public static function unformat($str)

Отдельно от всего этого вызывается test=Y, и именно он единственный влияет на итоговую оценку, которая выводится в строке «Конфигурация» — то самое число «попугаев».

Что измеряет test=Y

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

Процесс замера устроен так: на странице установлен хук OnAfterEpilog, который фиксирует время выполнения скрипта через microtime() и сохраняет его в сессии:

AddEventHandler('main', 'OnAfterEpilog', function() {     $main_exec_time = round(microtime(true) - START_EXEC_TIME, 4);     $_SESSION['PERFMON_TIMES'][] = $main_exec_time; });

Bitrix делает 9 последовательных запросов с test=Y и собирает 9 значений времени выполнения.

Пример результата:

["PERFMON_TIMES"] => array(   0 => 0.0452,   1 => 0.0452,   2 => 0.0479,   ...   8 => 0.0389 )

Как из времени получаются «попугаи»

Здесь всё просто: количество измерений делится на сумму времени всех запусков. Формула:

$result = number_format(     count($_SESSION['PERFMON_TIMES']) / array_sum($_SESSION['PERFMON_TIMES']),     2, '.', ' ' );

Если в среднем страница генерируется за 0.09 секунды, результат будет около 100 попугаев. Если за 0.15 — уже 60. Функция обратная, и это важный момент.

Проблема такой метрики

Главная проблема — гиперчувствительность этой метрики при малом времени отклика. Например:

• На CPU AMD EPYC средняя генерация страницы = 0.09 сек → 100 попугаев

• Незначительная нагрузка добавляет 2–3 мс → результат падает до 83

• При увеличении времени до 0.15 сек → остаётся 60 попугаев

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

Эпилог

Метрика производительности в Bitrix не учитывает CPU, файловую подсистему или поведение БД напрямую. Все параметры кроме test=Y служат только для информации и не влияют на итоговое число попугаев.

Формально, Bitrix считает не производительность системы, а обратную величину среднего времени генерации страницы, да ещё и на маленькой выборке.

Поэтому:

• Сравнивать разные сервера по этой метрике — ненадёжно

• Любые фоновые процессы могут «уронить» попугаев

• Повышение числа попугаев не всегда отражает реальный рост производительности

Если хотите объективную оценку — используйте внешние инструменты: профайлеры, нагрузочные тесты, мониторинг ресурсов. А попугаев оставьте для галочки.