PERCENTILE_CONT в SQL: как считать p50, p95 и latency

Рабочий вопрос

Почему среднее время ответа хорошее, а часть пользователей всё равно ждёт слишком долго?

Latency и время доставки часто имеют длинный хвост. Среднее сглаживает проблему, а максимум зависит от одной аномальной строки. Квантили дают устойчивый способ говорить о типичном и тяжёлом сценарии.

Если p50 checkout равен 1,2 секунды, а p95 — 6,8, большинство пользователей видит быстрый ответ, но хвост нуждается в отдельной диагностике по устройству, региону и endpoint.

Определение и grain

Для latency одна строка должна быть один завершённый запрос или один пользовательский опыт. Повторные retries нельзя смешивать с успешным результатом без отдельного флага.

Сначала выбери единицу наблюдения и исключи технические дубли. Затем посчитай несколько процентилей на одной базе, рядом укажи n и сравни распределение по сегментам.

Если показатель строится по событиям, отдельно проверь повторную отправку, идентичность пользователя и часовой пояс. Если данные приходят из бизнес-системы, сопоставь техническое поле с тем, как команда реально принимает решение.

Разбор примера

Если p50 checkout равен 1,2 секунды, а p95 — 6,8, большинство пользователей видит быстрый ответ, но хвост нуждается в отдельной диагностике по устройству, региону и endpoint.

Не копируй пример в рабочий отчёт вслепую. Сначала замени названия таблиц и полей, проверь кардинальность связей и запиши, какие строки должны попасть в результат. Хорошая адаптация сохраняет логику, но делает допущения видимыми.

SELECT COUNT(*) AS requests, PERCENTILE_CONT(0.50) WITHIN GROUP (ORDER BY latency_ms) AS p50, PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY latency_ms) AS p95, AVG(latency_ms) AS mean_latency\nFROM request_log\nWHERE endpoint = '/checkout';

Где расчёт ломается

Нельзя считать p95 при маленьком n точной цифрой, склеивать разные endpoint и скрывать отсутствие запросов. Для тяжёлого хвоста проверь также p99 и долю выше SLA.

Отдельно протестируй пустой результат, NULL, дубль, граничную дату и объект без связанной записи. Эти случаи не являются редкими исключениями: именно они чаще всего превращают рабочий показатель в красивую, но неверную цифру.

• Не смешивай зрелые и незрелые периоды без отдельной подписи.
• Не заменяй проверку качества тем, что запрос просто выполнился.
• Не делай причинный вывод из одного разреза.

Что показывает график

График здесь нужен не для украшения статьи. Он помогает увидеть форму сигнала: тренд, разрыв между сегментами, хвост распределения или этап, на котором теряется объект. Сначала прочитай оси и единицы, затем сравни с таблицей и только после этого формулируй вывод.

На визуализации «Центр и хвост latency» сравнивай не только максимальное значение. Проверь, одинаковы ли базы, не скрыта ли неполная дата и не меняется ли знаменатель от категории к категории.

Проверь на своих данных

Возьми сто значений latency с одним длинным хвостом. Сравни mean, p50, p90 и p95, а затем напиши, какое действие следует из каждого показателя.

После упражнения напиши вывод в двух версиях. Первая — техническая: какие строки и условия дали результат. Вторая — для команды: что изменилось, насколько это надёжно и какое действие стоит проверить. Если эти версии противоречат друг другу, вернись к определению показателя.

• Собери контрольный пример из пяти-десяти строк.
• Сверь итог с независимым способом расчёта.
• Проверь хотя бы один крайний случай.
• Зафиксируй дату, версию схемы и ограничение.

Решение и продолжение

Для SLA показывай p95 или p99 вместе с размером выборки и долей нарушений. Для продуктового опыта не забывай про перцентили, но связывай их с конкретным сценарием пользователя.

Сильный аналитический материал не обещает абсолютной уверенности. Он показывает, как получить число, где оно может ошибиться и какое решение можно принять уже сейчас. Такой формат хорошо переносится в дашборд, SQL-тренажёр, собеседование и рабочее обсуждение с командой.