Performance-метрики описывают разные стороны поведения системы. RPS показывает интенсивность запросов, throughput — объём выполненной работы, latency — задержку в выбранных границах, а percentiles помогают увидеть распределение времени. Если смешать эти значения, можно получить убедительный график и неверный вывод.
Для QA полезнее задать несколько связанных вопросов: сколько работы поступило, сколько завершилось успешно, как долго ждал пользователь и что происходило с очередью. Одна цифра редко отвечает на них все.
RPS: сколько запросов за секунду
RPS означает requests per second. Но нужно уточнить, где считаются запросы: генератором при отправке, балансировщиком при приёме или приложением после завершения. В нестабильном окне эти значения различаются из-за очередей, обрывов и незавершённых операций.
Записывай интервал агрегации и точку наблюдения. 6 000 запросов за минуту дают в среднем 100 RPS, но внутри минуты могли быть 20 секунд перегрузки и затем тишина. Средняя интенсивность не описывает форму поступления. Отдельно учитывай retries: рост RPS может быть следствием повторов, а не новых пользовательских задач.
Throughput: какая работа завершена
Throughput — пропускная способность в выбранных единицах: запросах, сообщениях, мегабайтах или заказах за единицу времени. Всегда называй единицу и определение успеха. Сто ответов в секунду, из которых половина — ошибки, не равны ста успешным заказам.
Полезно различать общий и полезный throughput. Если оформление заказа содержит пять API-запросов, завершённый заказ считается по бизнес-результату, а не делением общего HTTP-счётчика на пять: часть сценариев могла оборваться посередине. Для асинхронного процесса принятие задания и его успешное завершение — также разные события.
Latency и границы измерения
Слово latency используется неодинаково. Уточняй начало и конец: до первого байта, до полного ответа, от нажатия до появления результата или от помещения сообщения в очередь до обработки. Серверные 100 мс не включают автоматически сеть, ожидание соединения и отрисовку интерфейса.
Названия метрик инструмента тоже требуют чтения документации. Например, k6 http_req_duration складывает отправку, ожидание ответа и получение; начальное установление соединения учитывается отдельно. Нельзя без пояснения сравнивать это значение с временем пользовательского маршрута или метрикой сервера с другими границами.
Percentiles: что скрывает среднее
p95 — значение, около которого проходит граница 95% наблюдений в выбранной выборке; оставшийся хвост может быть значительно медленнее. Для точного результата важны метод вычисления и размер выборки. p50 описывает середину распределения, p99 — более редкие задержки.
Представь 100 ответов: 95 по 100 мс и пять по 3 секунды. Среднее составляет 245 мс, но пять пользователей ждали очень долго. По методу nearest-rank p95 равен 100 мс, p99 — 3 секундам; интерполяционный метод может дать другую границу. Поэтому указывай инструмент и анализируй распределение вместе с количеством наблюдений.
Почему нельзя усреднять percentiles
Среднее p95 двух серверов не становится общим p95. У серверов могут быть разные числа запросов и совершенно разные распределения. Аналогично нельзя получить percentile всего теста усреднением значений за отдельные минуты.
Для объединения нужны совместимые исходные наблюдения или подходящая агрегируемая гистограмма, из которой вычисляется quantile. Prometheus отдельно объясняет различие гистограмм и заранее рассчитанных quantiles в summaries. У гистограмм результат может быть оценочным: точность зависит от представления распределения. В отчёте не стоит показывать ложную точность до микросекунды, если метод её не обеспечивает.
Ошибки, очередь и конкурентность
Скорость ответов рассматривай вместе с долей ошибок, timeout, отмен и незавершённых операций. Система может быстро отказывать всем новым запросам, улучшая общую latency и одновременно переставая выполнять работу. Разделение успешных и неуспешных ответов делает это заметным.
Наблюдай количество активных запросов и очередь. При одинаковом входящем потоке увеличение времени обслуживания часто ведёт к накоплению работы. Виртуальные пользователи, активные HTTP-запросы и реальные пользователи — разные величины. Если модель закрытая, замедление может снизить создаваемый поток и скрыть перегрузку; это надо учитывать при интерпретации.
Практический пример: очередь экспорта
За пять минут генератор начал 3 000 заданий, сервер принял все, но успешно сформировал только 2 400 файлов. Остальные 600 ещё ожидают обработки. Средняя интенсивность поступления — 10 заданий в секунду, полезная скорость завершения — 8 файлов в секунду за это окно. Очередь выросла на 600 заданий, если исходно была пустой и иных исходов не было.
API приёма мог отвечать с p95 150 мс, но это не означает экспорт за 150 мс. Измерь отдельно время до принятия, ожидание очереди и время до доступного корректного файла. Учебный критерий «99% экспортов готовы за 30 секунд» проверяется по жизненному циклу задания, включая не завершившиеся в срок.
Как собрать результат прогона
До теста определи, какие события считаются успешными и что входит в знаменатель. Синхронизируй временные окна клиента и сервера, отдели прогрев и сохрани идентификаторы сценариев. Показывай метрики по операциям: поиск и экспорт нельзя бездумно объединять в одно распределение.
В отчёте укажи заданную и достигнутую интенсивность, число начатых и завершённых операций, ошибки, p50/p95/p99, единицы и метод измерения. Дополняй итог временными рядами: краткий провал может исчезнуть в хорошем результате за час. Если генератор пропускал старты из-за собственных ограничений, пометь тест как ограниченный этим фактором.
Что должен вынести QA из этой темы
RPS описывает поток запросов, throughput — выполненную работу, latency — время в заданных границах, percentiles — распределение наблюдений. Эти метрики полезны вместе с ошибками и очередями. Проверяй определения и способы агрегации: аккуратный расчёт важнее красивого числа в отчёте.