07.08.2025 07:06
MrPizzly 0 251 Источник

В рамках одной из внутренних задач коллега занимался исследованием того, как 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 считает не производительность системы, а обратную величину среднего времени генерации страницы, да ещё и на маленькой выборке.

Поэтому:

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

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

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

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

Комментарии (0)