Почему производительность системы нельзя измерять одним бенчмарком
В отчёте красуется p99 на уровне сорока миллисекунд, графики зелёные, дашборд красивый — а пользователи в поддержке жалуются на тормоза. Одиночный бенчмарк почти всегда измеряет то, что удобно измерять, а не то, что болит. Разбираемся, где именно он обманывает и как строить измерения, которым можно верить.
У каждой команды есть история про бенчмарк, который наврал. У нас это была админка, которую ускорили вдвое по итогам трёх недель оптимизаций, а жалобы пользователей не изменились. Позже выяснилось: замедлялась не админка, а выгрузка отчётов, которая в бенчмарк просто не попала. С тех пор мы относимся к любому одиночному измерению как к улике, а не как к вердикту — и рассказываем, как выстроить измерения, после которых не приходится краснеть.
Любой бенчмарк — это модель нагрузки: упрощённая копия реальности, которая сохраняет часть свойств системы и отбрасывает остальные. Вопрос не в том, хороша модель или плоха, а в том, какие свойства она сохранила. Бенчмарк на тысячу строк с прогретым кэшем честно отвечает на вопрос «как быстро запрос работает в лучших условиях» и молчит обо всём остальном — о конкурсе за блокировки, о холодном кэше после рестарта, о соседях по железу.
Опасность в том, что упрощения никогда не нейтральны. Выбирая, что включить в тест, автор невольно выбирает и результат. Если замерять только типовые сценарии, система будет выглядеть быстрой ровно до первого нетипового дня. Если замерять пик, она будет выглядеть готовой к нагрузке, которой никогда не бывает. Бенчмарк, который все устраивают и никто не перечитывает, измеряет не систему, а привычки команды.
«
Бенчмарк — это анкета, которую система заполняет о себе сама. Проблема начинается там, где вопросы анкеты подобраны под желаемый ответ.
Разрыв между тестовым стендом и продакшеном складывается из четырёх щелей. Первая — объём данных: запрос, мгновенный на тысяче строк, ведёт себя иначе на десяти миллионах, когда статистика плана устаревает и планировщик ошибается. Вторая — температура кэша: в тесте всё горячее, в проде ночью выгружают отчёты и вымывают страницы из буфера. Третья — профиль запросов: реальный трафик никогда не бывает равномерным, он пульсирует с расписанием людей. Четвёртая — конкурентность: параллельные транзакции порождают блокировки, которых не существует в однопоточном тесте.
Что измеряют разные метрики
Метрика
Что показывает
Где обманывает
Средняя задержка
Общее самочувствие системы
Прячет выбросы: 1% медленных запросов портит опыт, а среднее стоит на месте
Медиана (p50)
Типичный запрос
Не видит тяжёлый хвост, на котором живут жалобы пользователей
p99
Хвост задержек
Сам усредняется: редкий, но системный сбой в нём растворяется
RPS
Максимальную пропускную способность
Отвечает на вопрос «сколько влезет», а не «насколько быстро работает система»
Ни одна метрика из таблицы не плоха — плохой бывает интерпретация. Средняя задержка прекрасно отслеживает общий дрейф производительности от релиза к релизу. p99 незаменим, когда надо понять, почему сужается очередь. Ошибка начинается, когда одну метрику назначают единственной целью: оптимизация под неё почти всегда происходит за счёт метрик, которые в отчёт не попали.
Полностью повторить продакшен на стенде невозможно, и не нужно. Задача скромнее: сделать так, чтобы измерения предсказывали пользовательский опыт хотя бы по порядку величины. Список правил, который у нас работает.
— Фиксируйте профиль реального трафика: распределение запросов, размеры выборок, конкурентность — бенчмарк обязан повторять форму, а не только объём;
— Данные — продакшен-объёма: анонимизированный слепок или синтетика с реалистичным распределением длин и связей;
— Мерьте на пользовательском конце: RUM-метрики показывают то, что видит браузер, включая сеть и рендер, а не только сервер;
— Каждое изменение профиля нагрузки — новый бенчмарк: старые цифры не переносятся на новые условия;
— Сравнивайте только пары измерений из одной серии: прогрев, интервалы, версия железа должны совпадать;
— Регресс должен ловиться алертом, а не находиться при разборе инцидента — разовые отчёты не защищают.
Хорошая пара к статичным бенчмаркам — игровые дни: регулярные прогоны реального профиля нагрузки против теневой копии продакшена. Стоит это дорого, но именно они ловят то, что не ловит ничего: деградации, которые накапливаются от мелких изменений и в одиночных тестах просто не видны. Даже один игровой день в квартал заметно отрезвляет — особенно когда оптимизация из свежего спринта впервые встречается с честной нагрузкой.
И последнее: бенчмарки работают в паре с мониторингом. Измерения говорят, как система ведёт себя в известных условиях; мониторинг — как она ведёт себя на самом деле, прямо сейчас, на людях. Как выстроить вторую половину так, чтобы сигналы не тонули в шуме, мы разбираем в материале про алерты, которым действительно верят .
Одиночный бенчмарк не бесполезен — бесполезна вера в него. Относитесь к каждой цифре как к гипотезе, проверяйте её на продакшен-объёмах и держите рядом хотя бы три разных метрики. Система, которую измеряют с трёх сторон, обмануть не сможет даже очень старательный отчёт.
