Команда увеличивает нагрузку и видит рост RPS одновременно с ростом HTTP-ошибок. Какой показатель нужно считать пропускной способностью сервиса?
Пропускную способность следует оценивать по числу успешно завершённых целевых операций, а не по общему числу запросов или попыток. Общее количество запросов, долю ошибок и успешную пропускную способность нужно показывать раздельно: рост RPS при росте ошибок может означать не увеличение полезной производительности, а перегрузку.
Метрика запросов в секунду удобна для измерения технической активности системы, но сама по себе не показывает, сколько полезной работы выполнено. По мере усложнения распределённых систем появились повторы запросов, частичные сбои и ответы, формально успешные на HTTP-уровне, но не завершившие бизнес-операцию.
Поэтому в нагрузочном тестировании стали разделять offered load — предложенную нагрузку, throughput — фактически обработанный поток, и goodput — поток успешных результатов. Такое разделение помогает отличать рост активности от роста полезной производительности.
Предположим, генератор отправляет 1000 запросов в секунду. Если сервис успешно обрабатывает 950 операций, его полезная пропускная способность близка к 950 операциям в секунду. Если после увеличения нагрузки он принимает 1200 запросов, но успешно завершает только 800 операций, рост RPS не является улучшением.
Неверный выбор метрики может привести к ошибочному выводу о достижении цели производительности. Дополнительно возрастает риск скрыть деградацию: ошибки, повторы и тайм-ауты создают нагрузку, но не дают пользователю нужного результата.
Сначала нужно определить, что считается успехом для проверяемой операции. Для простого чтения это может быть корректный ответ с допустимым содержимым; для оформления заказа — подтверждённая запись в системе и соблюдение бизнес-инвариантов, а не только получение ответа с кодом 2xx.
В отчёте следует разделять как минимум четыре показателя:
Goodput лучше связывать с завершёнными бизнес-операциями, если цель теста — оценить способность системы обслуживать пользователей. При этом технический throughput тоже важен: ошибочные запросы потребляют CPU, соединения, память, сетевые ресурсы и могут быть причиной узкого места.
Повторы требуют особой осторожности. Один пользовательский запрос может породить несколько сетевых попыток, поэтому подсчёт попыток способен искусственно завысить RPS. В отчёте нужно явно указать, на каком уровне ведётся подсчёт: сетевой запрос, внутренняя операция или завершённый бизнес-результат.
HTTP-код нельзя использовать как единственный критерий успеха. Ответ 2xx может означать лишь принятие асинхронной задачи, а не её завершение; наоборот, техническая ошибка на одном промежуточном вызове иногда компенсируется повтором и приводит к успешному итоговому результату.
Ограничение подхода в том, что goodput зависит от корректно заданных критериев успешности. Если проверяется только один endpoint без проверки результата, можно получить формально высокий goodput при повреждённых или неполных данных. Поэтому критерии должны быть согласованы с владельцем сервиса и проверяться независимо от генератора нагрузки.
При тестировании оформления заказа генератор увеличил поток с 800 до 1200 попыток в секунду. Число ответов выросло, но доля ошибок поднялась с 1% до 25%, а число фактически созданных заказов снизилось с 790 до 760 в секунду.
Рассматривались три варианта. Считать все ответы — просто, но это смешивает успешные и ошибочные операции. Считать только ответы с кодом 2xx — лучше отражает технический результат, но может засчитать подтверждение асинхронного задания без реально созданного заказа. Считать подтверждённые бизнес-операции — наиболее точно, однако требует корреляции результатов и дополнительной проверки состояния системы.
Выбрали третий вариант, а рядом публиковали общий RPS, процент ошибок и число повторов. Результат показал, что предел системы наступал раньше, чем предполагалось по RPS: после 800 успешных заказов в секунду дальнейшее увеличение нагрузки только наращивало ошибки и повторы. Это позволило искать узкое место по моменту насыщения, не принимая техническую активность за производительность.
Ответ: Нет. Код 2xx описывает результат HTTP-взаимодействия, но не обязательно завершение целевой операции. Например, ответ о принятии фоновой задачи может быть успешным на транспортном уровне, пока сама задача завершится ошибкой. Критерий должен учитывать семантику конкретной операции и, при необходимости, проверять итоговое состояние.
Ответ: Нет, их нужно исключать из показателя полезной пропускной способности, но не из анализа нагрузки. Ошибочные запросы расходуют ресурсы и помогают определить момент насыщения, характер отказа и влияние повторов. Поэтому в отчёте должны присутствовать и goodput, и общий поток попыток, и распределение ошибок.
Ответ: Повторы увеличивают число технических запросов на одну пользовательскую операцию. Из-за этого RPS может расти даже при неизменном или снижающемся числе успешно завершённых операций. Для корректного анализа нужно отдельно учитывать исходные пользовательские операции, все попытки и итоговые успешные результаты, иначе нагрузка и производительность будут измеряться на разных уровнях.