Получить доступ

Почему время ответа измеряют перцентилями, а не средним?

MiddleЗадержка, пропускная способность и очереди
Ещё спрашивают так:
  • Что такое p99 и зачем он нужен?
  • Почему среднее время ответа обманывает?
  • Почему хвостовые задержки важны при fan-out?
Коротко

Распределение задержек сильно скошено: большинство запросов быстрые, но есть длинный хвост. Среднее его прячет, а p95/p99 показывает, что видят самые невезучие пользователи.

  • p99 = 300 мс: 99% запросов быстрее, 1% — медленнее
  • Страница делает 100 запросов к бэкенду — почти каждый пользователь попадает в чужой p99
  • Перцентили нельзя усреднять между серверами — нужны гистограммы

А ещё SLO формулируют так: «p99 < 300 мс за 28 дней» и следят за бюджетом ошибок

Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.

Попробуйте сами

Очередь и утилизация: почему при 90% всё тормозит

Подробно

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

Почему среднее плохо:

  • 99 запросов по 10 мс и один по 5 секунд дают среднее 60 мс — ни один запрос так не работал;
  • среднее почти не реагирует на деградацию хвоста, а пользователи реагируют;
  • медиана (p50) показывает типичный опыт, но тоже не видит хвоста.

Перцентили. p95 — значение, быстрее которого 95% запросов. Смотрят обычно p50, p95, p99, p99.9 и максимум.

Почему хвост важнее, чем кажется:

  • самые медленные запросы часто у самых ценных клиентов — у них больше данных, длиннее корзины;
  • fan-out: если ответ собирается из N параллельных вызовов, он ждёт самый медленный. Вероятность, что все 100 вызовов уложатся в свой p99, — 0,99¹⁰⁰ ≈ 37%. Значит, у 63% ответов задержка не лучше p99 одного бэкенда;
  • одна страница — десятки запросов: за сессию пользователь почти наверняка встретит p99.

Как правильно измерять:

  • гистограммы, а не готовые перцентили: перцентили с разных серверов нельзя усреднять, а гистограммы можно сложить и посчитать перцентиль по сумме (Prometheus histogram, HdrHistogram);
  • измерять на стороне клиента, а не только сервера — сервер не видит время в очереди перед собой и сеть;
  • coordinated omission — генератор нагрузки, который ждёт ответа перед следующим запросом, во время зависания просто не отправляет запросы и занижает хвост. Нужен генератор с постоянной скоростью (wrk2, k6 с arrival rate).

SLO. Цель формулируют через перцентиль и окно: «99% запросов за 28 дней быстрее 300 мс». Остаток до 100% — бюджет ошибок: пока он есть, можно выкатывать рискованное.

Пример

Задержки 10 000 запросов:
p50 = 12 мс   p90 = 25 мс   p99 = 180 мс   p99.9 = 1,4 с   среднее = 21 мс
Агрегатор вызывает 50 таких сервисов параллельно:
вероятность, что все быстрее p99: 0,99^50 ≈ 0,61 → 39% ответов агрегатора ≥ 180 мс

Что хотят услышать

  • Скошенное распределение и почему среднее вводит в заблуждение.
  • Смысл p95/p99 и что они показывают.
  • Эффект fan-out на хвост с расчётом.
  • Гистограммы, измерение у клиента, coordinated omission — для middle+.

Частые ошибки

  • Усреднять p99 по серверам.
  • Ставить SLO на среднее время ответа.

Что спросят дальше

Связанные вопросы

Закрытая бета

Подсказки на собеседовании — в реальном времени

sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.

  • Промокод на 2 часа — сверх пробных 30 минут
  • Программа для Windows — скачать сразу, войти — через Яндекс ID или VK ID
  • Прямая связь с разработчиком: что улучшить — сделаем