В отчёте нагрузочного теста средняя задержка укладывается в SLA, но p99 значительно выше. Какой вывод о качестве сервиса следует сделать?
Средняя задержка не описывает опыт наиболее медленных запросов. Если p99 значительно выше допустимого значения, сервис нарушает требования для примерно одного процента запросов, поэтому считать его производительность приемлемой только по среднему нельзя.
Нужно проверить SLA на том показателе, который действительно ограничивает пользовательский опыт: например, на p95, p99 или максимальной задержке. Одновременно следует искать причину длинного хвоста распределения, а не пытаться объяснить проблему только средним значением.
Средние значения долго использовались как простой способ свести большой объём результатов теста к одному числу. Такой подход удобен для сравнения запусков, но он скрывает редкие задержки, которые могут быть критичны для пользователей и распределённых систем.
Поэтому в анализе производительности стали применять перцентили. Они показывают положение значения в упорядоченном распределении и позволяют отдельно контролировать обычный и хвостовой пользовательский опыт.
Предположим, средняя задержка равна 200 миллисекундам, а p99 — 8 секундам. Большинство запросов выполняется быстро, но каждый сотый запрос существенно задерживается.
Среднее может оставаться низким даже при тяжёлом хвосте, особенно если медленные запросы редки. Это опасно для интерактивных операций, цепочек микросервисов и пользовательских сценариев, где один медленный вызов задерживает весь результат.
Неверный вывод приводит к преждевременному выпуску системы, недооценке тайм-аутов и пропуску периодических проблем с базой данных, сборкой мусора, блокировками, очередями или внешними зависимостями.
Перцентиль p99 — это значение задержки, ниже которого находится примерно 99 процентов измеренных запросов. Оставшийся примерно один процент запросов имеет задержку не меньше этого уровня; это не означает, что все они имеют одинаковую задержку или что p99 является абсолютным максимумом.
Анализируют несколько показателей одновременно: количество запросов, среднюю задержку, медиану, p95 или p99, ошибки, тайм-ауты и временную динамику. Если хвост растёт при увеличении нагрузки, это может указывать на накопление очереди, исчерпание пула соединений, блокировки или насыщение ресурса.
Важно сопоставлять задержки с корректно измеренным объёмом запросов. При малом числе наблюдений p99 нестабилен: один запрос может заметно изменить результат. Для разных операций и пользовательских маршрутов следует строить отдельные распределения, потому что общий p99 способен скрыть проблемы конкретного критичного сценария.
Нельзя автоматически считать любое высокое значение p99 дефектом одного сервиса. Задержка может возникать на клиенте, в сети, в балансировщике, зависимом сервисе или в инструменте генерации нагрузки. Поэтому перцентиль нужно связывать со временем, трассировками, метриками ресурсов, глубиной очередей и разбивкой по типам запросов.
Компромисс состоит в том, что контроль только p99 может сделать критерий слишком чувствительным к редким внешним событиям, а контроль только среднего — скрыть плохой опыт части пользователей. На практике заранее задают целевой перцентиль, минимальный объём выборки и правила обработки ошибок и тайм-аутов.
В интернет-магазине средняя задержка оформления заказа во время теста составила 240 миллисекунд, p95 — 420 миллисекунд, а p99 — 6,5 секунды. При этом доля ошибок была ниже одного процента, поэтому команда сначала объявила результат успешным.
Рассмотрели три варианта:
Выбрали третий вариант. Оказалось, что небольшая доля операций ожидала свободное соединение с базой данных, после чего задержка резко возрастала. Пул расширили в пределах безопасной нагрузки на базу, а критерий приемки сформулировали через p95 и p99 при заданном объёме запросов; после изменения p99 снизился до 1,1 секунды.
Нет, такой показатель имеет низкую статистическую устойчивость. При 200 наблюдениях p99 фактически определяется одним из самых медленных запросов, поэтому небольшое случайное изменение может сильно повлиять на результат.
Нужно обеспечить достаточный объём выборки для каждого отдельного сценария и сравнивать не только одно число, но и распределения, повторные прогоны и доверительные интервалы, если требования к точности высоки. Объём выбирают с учётом целевого перцентиля, длительности теста и ожидаемой частоты редких событий.
Перцентиль нельзя надёжно получать как простое среднее перцентилей отдельных узлов. У генераторов могут быть разное число запросов и разные распределения задержек; усреднение потеряет информацию о глобальном хвосте.
Для итогового показателя нужно объединять наблюдения или использовать корректный метод агрегирования распределений. Кроме того, следует проверять, что сами генераторы не стали узким местом и не добавили задержку к измерению.
Нет. Высокий хвост может быть вызван блокировками, паузами сборки мусора, задержками сети, редкими медленными запросами к хранилищу, исчерпанием пула соединений, зависимым сервисом или ошибкой измерения.
Вывод о причине делают по корреляции во времени и по разрезам: сравнивают задержки с загрузкой процессора, памятью, дисковым вводом-выводом, очередями, количеством соединений, тайм-аутами и трассировками. Сам p99 показывает наличие проблемы в хвосте, но не доказывает, какой компонент её вызвал.