В новой версии сервиса p99 задержки снизился, но p50 вырос. Как определить, улучшилась ли производительность на самом деле?
Однозначного вывода по одному p99 сделать нельзя: производительность изменилась неравномерно. Нужно сопоставить полное распределение задержек с целевыми SLA, долями пользовательских операций и бизнес-приоритетами: снижение хвоста может быть улучшением для редких медленных запросов, но рост p50 означает ухудшение для типичного запроса.
Среднее время ответа плохо описывает системы с несимметричным распределением задержек: небольшая доля долгих запросов может существенно влиять на среднее, а большинство пользователей этого не заметит. Поэтому в нагрузочном тестировании стали использовать перцентили, позволяющие отдельно оценивать типичный и хвостовой опыт.
p50 показывает задержку, которую не превышает половина запросов, а p99 — задержку, которую не превышает 99% запросов. Если p50 вырос, большинство запросов стало медленнее; если p99 снизился, самые медленные запросы стали быстрее или исчезли.
Неверно объявлять релиз успешным только из-за улучшения p99. Это может скрыть регрессию для основной массы пользователей, особенно если SLA задан одновременно для нескольких перцентилей или разные операции имеют разную критичность.
Сначала нужно сравнить версии на одинаковых условиях: составе операций, их пропорциях, данных, длительности теста, модели нагрузки и прогреве. Затем следует изучить как минимум p50, p90, p95, p99, максимальную задержку, долю ошибок и количество наблюдений.
Полезно построить график распределения задержек или гистограмму. Он покажет, действительно ли хвост сократился, либо изменился только расчётный перцентиль из-за другой формы распределения. Один и тот же p99 может быть получен при совершенно разных задержках между p50 и p99.
Далее результаты нужно разделить по операциям, маршрутам, размерам ответа и другим значимым группам. Общие перцентили могут скрыть ситуацию, в которой редкая, но критичная операция улучшилась, а массовая операция ухудшилась.
Решение зависит от целей системы. Если приоритет — интерактивный пользовательский интерфейс, рост p50 может быть неприемлемым даже при снижении p99. Если приоритет — устранение редких тайм-аутов, снижение хвоста может иметь больший вес, но это должно быть явно отражено в критериях приёмки.
Для статистической уверенности нужны повторные прогоны или доверительные интервалы. Небольшое изменение p50 или p99 в одном прогоне нельзя считать доказанной регрессией либо улучшением без оценки разброса измерений.
После изменения планировщика запросов p50 вырос с 80 до 95 миллисекунд, а p99 снизился с 2 секунд до 700 миллисекунд. Команда рассматривала два варианта: откатить изменение, сохранив прежнюю типичную скорость, или оставить его ради устранения редких очень долгих запросов.
Откат сохранял комфортную задержку большинства запросов, но оставлял риск тайм-аутов для части пользователей. Оставить изменение без дополнительного анализа было опасно, поскольку массовый сценарий уже замедлился.
Команда разделила результаты по операциям и добавила критерии для p50 и p99. Выяснилось, что рост p50 пришёлся на часто используемый поиск, а снижение p99 — на редкую административную операцию. Изменение отклонили для поиска, а оптимизацию административного сценария внедрили отдельно: так удалось не обменивать массовое ухудшение на улучшение менее значимого хвоста.
Нет, без контекста это лишь изменение формы распределения. Нужно проверить целевые перцентили, долю запросов каждого типа и влияние на пользователей. Улучшение одного участка распределения не компенсирует автоматически ухудшение другого.
Если в двух прогонах различаются пропорции операций, общий перцентиль может измениться из-за состава выборки, а не из-за работы сервиса. Сравнивать следует одинаковый профиль нагрузки и, при необходимости, отдельные распределения по операциям.
p99 описывает только одну точку распределения и не показывает, насколько далеко находятся p99,9 или максимальные значения. Два теста могут иметь одинаковый p99, но разную долю экстремально долгих запросов и разный риск тайм-аутов. Поэтому для критичных систем дополнительно анализируют более высокие перцентили, тайм-ауты и длительность окон нарушения SLA.