P95 и P99: почему среднее время ответа скрывает медленные запросы
P95 и P99 времени ответа показывают границу, в которую укладывается выбранная доля измеренных запросов. Эти показатели помогают увидеть медленные ответы, которые теряются за хорошим средним значением. Если большинство посетителей получает ответ быстро, а небольшая группа ждёт несколько секунд, один график среднего времени может выглядеть вполне благополучно.
Для бизнеса эта разница важна в конкретных действиях: поиске товара, расчёте доставки, входе в кабинет, отправке заявки. Однако высокий перцентиль сам по себе ещё не объясняет причину задержки. Сначала нужно понять, какие запросы попали в расчёт, где измеряли время и сколько наблюдений собрали. Затем можно выбирать порог и искать проблемный участок.
Разберём среднее время ответа и P95 на условных числах, покажем типичные ошибки агрегации и составим практическую схему наблюдения за серверными запросами. Все значения в примерах учебные: это не норматив скорости и не статистика конкретного проекта.
Что означают P50, P95 и P99
Представьте список длительностей запросов, отсортированный от самого быстрого к самому медленному. P50 находится в середине этого распределения, P95 — ближе к его концу, P99 — ещё дальше. Высокие значения называют хвостовыми перцентилями: они помогают описать небольшую, но потенциально важную группу медленных операций.
При используемом ниже методе ближайшего ранга P95, равный 800 мс, означает, что не менее 95% наблюдений укладываются в 800 мс. Это не среднее время самых медленных пяти процентов. P99 не обязательно совпадает с максимальной задержкой: выше него могут оставаться очень долгие запросы, но на малой выборке он может оказаться максимумом.
Перцентиль времени ответа относится к запросам из конкретной выборки, а не автоматически к людям. Один посетитель может отправить несколько запросов, повторить неудачную попытку или столкнуться с несколькими медленными действиями подряд. Чтобы говорить о доле клиентов с неудобным опытом, нужна отдельная метрика пользовательского сценария.
Есть несколько алгоритмов вычисления перцентилей. Справочник NIST объясняет различия между распространёнными методами оценки. Поэтому небольшое расхождение между таблицей, аналитической системой и мониторингом не обязательно означает ошибку. В описании показателя фиксируют алгоритм или используемый инструмент, особенно для коротких выборок.
Пример: среднее 220 мс, а P99 — полторы секунды
Возьмём сто завершившихся запросов одного маршрута за одинаковое окно наблюдения. Для наглядности объединим одинаковые длительности в группы.
| Количество запросов | Длительность каждого | Места в отсортированном списке | Общая длительность |
|---|---|---|---|
| 90 | 100 мс | 1–90 | 9 000 мс |
| 5 | 400 мс | 91–95 | 2 000 мс |
| 4 | 1 500 мс | 96–99 | 6 000 мс |
| 1 | 5 000 мс | 100 | 5 000 мс |
Сумма длительностей равна 22 000 мс. Делим её на сто запросов и получаем среднее 220 мс. В этом примере применяем метод ближайшего ранга: номер позиции равен ceil(p × N), где p — доля от нуля до единицы, N — количество наблюдений, а ceil округляет вверх. Нумерация позиций начинается с единицы.
- P50: позиция 50, результат 100 мс.
- P95: позиция 95, результат 400 мс.
- P99: позиция 99, результат 1 500 мс.
- Максимум: позиция 100, результат 5 000 мс.
Среднее здесь не ошибается: оно правильно описывает сумму, распределённую на число операций. Но фраза «сайт отвечает за 220 мс» создаёт впечатление, которого данные не подтверждают. Пять запросов из ста заняли больше 400 мс, один — пять секунд. Для отправки коммерческой заявки такой эпизод заслуживает отдельного разбора, даже если большинство обращений проходит быстро.
Сначала определите, какое именно время измеряется
Надпись «время ответа» может скрывать разные интервалы. Приложение измеряет обработку внутри своего процесса. Прокси видит собственную границу приёма и передачи данных. Внешняя проверка включает сетевой путь от точки наблюдения. Браузер дополнительно выполняет код страницы и ждёт необходимые интерфейсу ресурсы.
Например, серверная операция может занимать 200 мс, тогда как проверка из другой сети фиксирует 600 мс. Эти числа нельзя объявлять противоречием без определения начала и конца измерений. Внешний результат мог включать установку соединения или передачу ответа; внутренний таймер мог начинаться уже после части подготовительных действий.
В Google SRE отдельно рассматривается разница между показателем, важным пользователю, и доступным техническим приближением. Для своей панели подпишите место измерения, единицу, маршрут и окно. Формулировка «P95 обработки POST /orders приложением за последние 15 минут» полезнее, чем «скорость сайта».
Также решите, что считать концом асинхронной операции. Быстрый ответ «задание принято» не доказывает, что отчёт сформирован или письмо отправлено. Здесь нужны два разных наблюдения: длительность HTTP-запроса и время до готового результата. Складывать их в одну неописанную метрику неудобно и для анализа, и для постановки задач разработчику.
Разделяйте запросы по смыслу и результату
Общий P95 всего сайта может улучшиться после роста количества простых обращений, хотя оформление заказа стало медленнее. Представьте, что рекламная кампания привела много просмотров закешированных карточек. Их быстрые ответы изменили распределение, а редкий расчёт доставки остался проблемным. Сводная цифра скрыла именно тот участок, который важен покупателю.
Начните с нескольких групп: карточка товара, поиск, корзина, создание заказа, отправка формы. Разделите HTTP-методы, если за одинаковым адресом стоят разные действия. Для расследования полезны версия приложения и окружение. Дополнительное дробление вводите, когда оно отвечает на конкретный вопрос, а не просто увеличивает количество линий.
В метриках используйте шаблон маршрута вроде /orders/{id}. Индивидуальные номера заказов и случайные параметры делают набор значений практически неограниченным. Такой подход к маршрутам закреплён в семантических соглашениях OpenTelemetry для HTTP-метрик. Конкретные адреса и диагностические идентификаторы удобнее исследовать в журналах с подходящими правилами доступа.
Обязательно показывайте ошибки рядом со скоростью. Быстрый отказ за 20 мс способен улучшить среднее и P95, хотя действие перестало работать. Полезно иметь распределение успешных ответов и отдельные счётчики неуспехов, тайм-аутов, отменённых операций. Отсутствие завершившегося запроса не должно превращаться в нулевую длительность.
Почему окно измерений и размер выборки меняют вывод
P99 за сутки и P99 за последние пять минут отвечают на разные вопросы. Суточный показатель описывает большой период, но способен скрыть короткую деградацию во время вечернего спроса. Короткое окно быстрее реагирует на изменение, однако при небольшом потоке запросов сильно зависит от отдельных наблюдений.
По методу ближайшего ранга для двадцати измерений P95 будет девятнадцатым значением, а P99 — двадцатым, то есть максимумом. Это корректный результат выбранного вычисления, но слабое основание для уверенного утверждения о типичном «медленном одном проценте» потока. Даже сто измерений не делают оценку хвоста автоматически устойчивой.
Показывайте рядом с перцентилем количество запросов. Для редко используемого маршрута можно увеличить окно или дополнить график списком медленных операций. Универсального минимального числа наблюдений для всех сайтов нет: оно зависит от изменчивости задержек, требуемой точности и решения, которое принимают по показателю.
Сравнивая недели, сохраняйте одинаковые условия. После изменения расписания проверки, состава маршрутов или метода сбора линия может сдвинуться без изменения приложения. Отмечайте релизы и изменения телеметрии. Пустое окно обозначайте как отсутствие данных: оно не подтверждает ни быструю работу, ни отсутствие проблем у посетителей.
Почему нельзя усреднять P95 разных серверов
Рассмотрим ещё один учебный пример. Сервер A обработал 900 запросов по 100 мс. Сервер B — 100 запросов по 1 000 мс. На первом P95 равен 100 мс, на втором — 1 000 мс. Простое среднее этих перцентилей составляет 550 мс; взвешенное по числу запросов — 190 мс.
Теперь объединим исходные наблюдения. В списке из тысячи значений первые девятьсот равны 100 мс, последние сто — 1 000 мс. P95 находится на позиции 950, поэтому правильный результат объединённой выборки — 1 000 мс. Ни 550, ни 190 мс его не заменяют. Последнее число здесь совпало со средним временем всех запросов, но это другой показатель.
Та же ошибка возникает при усреднении поминутных P99 ради суточного отчёта. Перцентиль уже потерял большую часть информации о распределении. По одному числу нельзя восстановить, сколько наблюдений находилось ниже него и насколько далеко лежал хвост.
Для общего результата объединяйте исходные измерения либо совместимые представления распределений, а затем вычисляйте нужный перцентиль. Отдельные показатели серверов сохраняйте для диагностики. Они полезны, чтобы заметить неравномерную нагрузку или проблемный экземпляр, но не становятся глобальным P95 после арифметического усреднения.
Что собирать: сумма, количество, гистограмма или summary
Сумма длительностей и количество наблюдений позволяют вычислить среднее: sum / count. Для P95 этих двух чисел недостаточно. Разные наборы запросов способны иметь одинаковое среднее при совершенно разных хвостах. Поэтому заранее проверьте, сохраняет ли система данные, необходимые для распределения.
Гистограмма хранит количество наблюдений в интервалах. Summary может выдавать заранее рассчитанные квантили. В документации Prometheus описаны различия этих типов и ограничения объединения готовых квантилей. Выбор зависит от инструментирования и того, понадобится ли рассчитывать общий показатель по нескольким экземплярам.
При работе с классической гистограммой границы интервалов должны помогать ответить на ваш вопрос. Если важный порог находится внутри очень широкого интервала, оценка перцентиля получается грубой. Для проверки доли запросов быстрее конкретного порога полезно предусмотреть соответствующую границу. Поддержку native histograms и её настройки уточняют для используемых компонентов.
Не пытайтесь получить точность, которой нет в исходных данных. Значение 0,793527 секунды на панели не гарантирует измерение с такой точностью. Лучше отображать разумное число знаков и знать ограничения сбора. Если сохраняется только выборка запросов, отдельно опишите правило отбора: преимущественное сохранение медленных операций меняет распределение.
Как может выглядеть расчёт в Prometheus
Ниже приведён пример для собственной классической гистограммы с условным именем site_http_request_duration_seconds. Предполагается, что она действительно собирает длительности, а метки job, route и status_class существуют. Это схема для адаптации, а не команда, которую можно без проверки вставить в любой проект.
histogram_quantile(
0.95,
sum by (le, route) (
rate(site_http_request_duration_seconds_bucket{
job="site", status_class="2xx"
}[5m])
)
)Выражение объединяет интервалы совместимых гистограмм по маршруту и оценивает P95 успешных ответов за пятиминутное окно. Для P99 меняют аргумент на 0.99. Метка le сохраняется, поскольку задаёт верхнюю границу интервала классической гистограммы. Если данные имеют другую структуру, запрос тоже будет другим.
Описание histogram_quantile в Prometheus уточняет правила агрегации и интерполяции. Полученное значение является оценкой по гистограмме и может отличаться от ближайшего ранга по полному списку. Рядом добавьте число наблюдений за то же окно и отдельную панель ошибок: фильтр 2xx исключил их из этого расчёта.
Как задать порог, после которого нужна реакция
Порог выбирают для конкретного действия. Поиск товаров и формирование большого отчёта могут иметь разные ожидания. Начните с наблюдений за обычной работой, жалоб пользователей и ограничений бизнес-процесса. Затем договоритесь, какое ухудшение требует немедленной реакции, а какое можно разобрать в плановом порядке.
Учебная формулировка: «P95 успешного создания заявки превышает 900 мс в нескольких последовательных оценках; объём наблюдений достаточен для принятого правила». Здесь нужно дополнительно определить окно расчёта, частоту оценки, минимальный объём и продолжительность превышения. Число 900 мс не является рекомендацией для всех сайтов.
Для редких, но критичных операций полезнее отдельное условие: конкретная отправка завершилась ошибкой либо превысила допустимое время. Ждать устойчивого P99 при нескольких заявках в час бессмысленно. Аналогично резкий рост тайм-аутов должен обнаруживаться независимо от того, насколько привлекательным остаётся график успешных ответов.
Сообщение ответственному должно содержать маршрут, окно, текущее значение, порог, количество запросов и ссылку на диагностические данные. После восстановления проверяйте не только возврат линии под границу, но и успешность нужного действия. Иначе быстро возвращаемая ошибка может выглядеть как устранённая проблема со скоростью.
Что делать, если P99 вырос после обновления
Предположим, после релиза заявки иногда отправляются медленно. Среднее почти не изменилось, а P99 заметно вырос. Начинайте с проверки сопоставимости: тот же маршрут, одинаковый фильтр статусов, единицы и окно. Убедитесь, что новый код не изменил сам таймер или метки.
- Проверьте объём. Один запрос в пустой период требует другого разбора, чем повторяющееся ухудшение при рабочей нагрузке.
- Сравните успешность. Посмотрите ошибки и тайм-ауты, чтобы понять, заканчиваются ли медленные действия нужным результатом.
- Локализуйте группу. Сопоставьте экземпляры приложения, версию релиза и маршруты, не смешивая их преждевременно.
- Найдите конкретные операции. Используйте время события, журналы и трассировки для поиска ожидания базы, внешнего ответа или очереди.
- Проверьте исправление. Повторите сравнение при сопоставимой нагрузке и подтвердите результат пользовательского действия.
Перцентиль подсказывает, где искать, но не доказывает, что виновата база данных, хостинг или разработчик. В нашем условном случае причиной мог стать дополнительный внешний запрос, выполняемый только для части заявок. Проверяемая гипотеза появляется после разбора операций, а не из названия метрики.
Что передать разработчику для настройки панели
Задача «добавить P95 и P99» допускает слишком много трактовок. Лучше оформить короткую карточку метрики. Тогда разработчик, владелец сайта и специалист поддержки смогут одинаково объяснить получившийся график и проверить результат внедрения.
| Поле карточки | Пример содержимого |
|---|---|
| Действие | Приём заявки через основной API сайта |
| Граница таймера | От входа в обработчик до завершения ответа приложения |
| Состав выборки | Production, выбранный маршрут, отдельно успешные и неуспешные операции |
| Период | Скользящее окно с явно указанной длительностью |
| Соседние показатели | Количество обращений, ошибки, тайм-ауты, свежесть данных |
| Реакция | Ответственный, условие уведомления, ссылка на инструкцию разбора |
Добавьте к карточке небольшой набор проверочных данных с известным результатом. Можно использовать пример из этой статьи или собственный список длительностей. Он нужен, чтобы обнаружить перепутанные единицы, неправильный фильтр и ошибочную агрегацию ещё до включения уведомлений. Проверять стоит и пустой набор: панель должна показывать отсутствие наблюдений, а не красивый ноль.
Отдельно согласуйте сравнение до и после исправления. Допустим, новую версию выпустили утром, а старую оценивали вечером при высокой нагрузке. Простое снижение P99 не доказывает эффект изменения. Возьмите сопоставимые маршруты, статусные группы и периоды нагрузки; убедитесь, что объём данных позволяет сравнение. Сохраните исходные условия рядом с выводом.
Наконец, укажите, кто поддерживает метрику после изменения приложения. Новый адрес формы, другой способ приёма заявки или перенос операции в очередь могут оставить старый график технически исправным, но бесполезным для бизнеса. Пересмотр определения показателя должен входить в работу над изменением самого процесса.
Частые вопросы о P95 и P99
Какое значение P95 считается хорошим?
Единой нормы для всех маршрутов нет. Нужны назначение операции, границы измерения и ожидание результата. Согласуйте показатель для конкретного действия и следите, чтобы улучшение задержки не сопровождалось ростом ошибок.
Нужно ли убрать среднее с панели?
Нет. Среднее помогает видеть общую динамику и сопоставлять суммарное время с количеством операций. Дополните его перцентилями, объёмом запросов и успешностью. Каждый показатель отвечает на свой вопрос.
Можно ли получить P99 посетителей из проверки раз в минуту?
Так можно описать распределение собственных измерений проверки, если данных достаточно для выбранного расчёта. Но оно не становится распределением запросов посетителей: маршрут, частота, география и условия отличаются. Подписывайте источник наблюдений явно.
Почему P99 пропал с графика?
Проверьте наличие наблюдений, фильтры, сбор метрики и корректность гистограммы. Отсутствующее значение нельзя заменять нулём и считать улучшением. Сначала восстановите достоверность данных, затем оценивайте скорость.
С чего начать контроль времени ответа
Выберите один важный маршрут, определите начало и конец измерения, соберите количество запросов, ошибки и распределение длительностей. Зафиксируйте окно и правило реакции. После этого расширяйте наблюдение на другие действия, сохраняя понятный смысл каждой панели.
Подключите SiteGuard для внешнего HTTP-контроля доступности важных страниц сайта.