RPS, latency, percentiles
Тема дорожной карты · QA-инженер
Метрики нагрузочного тестирования — это количественные измерения, которые QA-инженеры используют для оценки того, соответствует ли система нефункциональным требованиям под нагрузкой. Наиболее критичные метрики: пропускная способность (запросов в секунду, RPS), задержка (время от отправки запроса до получения последнего байта), процент ошибок и перцентильные времена ответа — особенно значения p95 и p99, раскрывающие хвостовую задержку, которую испытывают реальные пользователи. Инструменты JMeter, k6, Locust и Gatling собирают эти метрики нагрузочного тестирования автоматически и представляют их в дашбордах вместе с загрузкой CPU, потреблением памяти и паузами сборки мусора, помогающими локализовать узкие места на уровне инфраструктуры. Интерпретация перцентильных распределений вместо средних значений крайне важна в анализе метрик нагрузочного тестирования, поскольку средние значения скрывают выбросы, ухудшающие пользовательский опыт для значительной части трафика.
Как это работает
RPS, latency, percentiles валидирует поведение системы под нагрузкой. Инструменты: k6 (современный, на JavaScript, рекомендуется), JMeter (legacy, Java, GUI), Locust (Python, скриптуемый), Gatling (Scala, code-first), Artillery (Node). Типы: load (ожидаемый трафик, sustained), stress (за пределами ожидаемого — точка слома), spike (внезапный всплеск), soak (многочасовая выдержка — ловит утечки), capacity (максимум sustainable). Метрики: throughput (req/s), latency (p50, p95, p99), error rate.
Когда применять
Гоняйте perf-тесты до запуска (find capacity), до major-релизов (regression), после изменений архитектуры. Тестируйте против production-shaped среды — не "ноут с моками". Всегда меряйте p95/p99 latency, не только average (average прячут outliers). Распределённую load-generation — если трафик > одной машины. SLO сначала; perf-тесты их верифицируют.
Типичные ошибки
Ловушки RPS, latency, percentiles: load-тестируете свой ноут вместо целевой среды (результаты бесполезны); не прогрели систему до замеров (cold-cache цифры неверны); load генерируется из той же сети, что и target (меряете локальную сеть, не систему); не тестируете think-time (реальные юзеры не долбят refresh постоянно).