Сервис выдерживает целевой RPS с маленькими ответами, но резко теряет производительность с большими. Какой механизм нагрузки следует проверить первым?
Нужно проверить, как размер полезной нагрузки увеличивает стоимость одного запроса и переводит систему на другой ресурсный предел. Большие ответы могут перегрузить сеть, сериализацию, сжатие, память или сборку мусора, поэтому одинаковый RPS не означает одинаковую нагрузку.
Нагрузочные тесты изначально стремились воспроизводить не только число запросов, но и характер реального трафика. Это необходимо потому, что производительность зависит от объёма обрабатываемых данных, а не только от частоты обращений.
Модель «фиксированный RPS без учёта размера сообщений» удобна для сравнения, но может скрыть критический сценарий. Поэтому реалистичная модель нагрузки обычно учитывает распределения размеров запросов и ответов.
Два теста с одинаковым RPS могут предъявлять системе принципиально разные требования. Малый ответ почти не расходует пропускную способность сети и память, тогда как большой требует больше времени на формирование, сериализацию, передачу и, возможно, сжатие.
Если тестировать только маленькие сообщения, можно ошибочно объявить систему готовой к SLA. В эксплуатации при больших payload вырастут задержки, снизится пропускная способность, появятся тайм-ауты или начнёт насыщаться ресурс, который не был узким местом в упрощённом тесте.
Размер payload увеличивает работу на один запрос. Для ответа это может означать построение большего объекта, сериализацию в текстовый формат, копирование буферов, сжатие и передачу через сетевой стек.
Если ограничивающим ресурсом становится сеть, растёт время передачи и очередь на сетевых интерфейсах. Если исчерпывается CPU, следует проверить сериализацию и компрессию. Если возрастает потребление памяти, возможны давление на аллокатор, более частые сборки мусора и рост хвостовых задержек.
Поэтому сравнивать следует не только RPS и среднюю задержку, но и байты в секунду, распределение размеров payload, загрузку сетевых интерфейсов, CPU по процессам и потокам, потребление памяти, частоту и длительность сборок мусора, а также задержки по этапам обработки.
Корректная модель должна содержать реалистичное распределение размеров сообщений, а не одно среднее значение. Средний размер может скрыть редкие, но тяжёлые ответы, которые формируют p95 или p99.
Увеличение размера payload не доказывает само по себе, что узким местом является сеть. Один и тот же симптом может возникать из-за сериализации, компрессии, ограничений буферов или downstream-компонента. Причину подтверждают корреляцией задержек и утилизации ресурсов при контролируемом изменении размера сообщений.
Команда проверяла API каталога при целевом RPS. В первом варианте все ответы имели небольшой размер, и SLA выполнялся. После перехода к реалистичному распределению, включавшему крупные ответы, p99 вырос, хотя RPS остался тем же.
Рассматривались три варианта. Увеличение числа экземпляров приложения могло повысить суммарную CPU-мощность, но не решало общий предел сетевого канала. Отключение сжатия уменьшало нагрузку на CPU, однако резко увеличивало объём передаваемых данных. Уменьшение ответа снижало сетевую и CPU-нагрузку, но требовало изменить контракт API.
Выбрали оптимизацию формата ответа и перенос редко нужных полей в отдельный запрос, после чего отдельно проверили крупные ответы. Это решение уменьшило работу на обычный запрос и устранило ложное ощущение, что сервис ограничен только вычислительной мощностью. Результат следует оценивать по p95/p99, байтам в секунду и ресурсным метрикам, а не по одному RPS.
Ответ: Нет. Среднее значение не показывает форму распределения и может скрыть редкие крупные сообщения. Нужно анализировать квантили или гистограмму размеров, долю крупных payload и их вклад в p95 или p99 задержки.
Ответ: Нужно сопоставить рост задержки с независимыми метриками. Сетевое ограничение подтверждается ростом передаваемых байтов и загрузки интерфейсов или каналов при относительно стабильном CPU, а дорогая сериализация — ростом CPU соответствующего процесса или этапа при отсутствии насыщения сети. Для уверенного вывода полезно отдельно измерять время формирования ответа и время передачи.
Ответ: Да. Удаление данных или перенос их в дополнительные запросы снижает стоимость одного ответа, но увеличивает число обращений, усложняет клиентскую логику и может повысить суммарную задержку сценария. Поэтому решение нужно проверять на уровне полного пользовательского сценария: учитывать число запросов, суммарный объём данных, его задержку и соблюдение функционального контракта.