Практическая ситуация: на ступенчатом нагрузочном тесте генератор достигает предела CPU раньше приложения. Какой вывод о результатах теста корректен?
Результаты нельзя считать измерением предельной производительности приложения: первым ограничился генератор нагрузки. Тест в этой точке показывает пропускную способность связки генератор–сеть–приложение, а не обязательно предел самого сервиса.
Нужно увеличить запас генератора или распределить нагрузку между несколькими генераторами и повторить тест. Только после этого можно интерпретировать насыщение ресурсов приложения и его целевые метрики.
Нагрузочные тесты используют отдельные генераторы, потому что один клиентский процесс часто не способен создать требуемое число запросов и соединений. Генератор выполняет работу, которая не относится к тестируемому сервису: планирует виртуальных пользователей, устанавливает соединения, шифрует трафик, сериализует запросы, принимает ответы и собирает измерения.
Поэтому в нагрузочном тестировании важно разделять ограничения системы под тестом и ограничения испытательного стенда. Иначе ресурс генератора ошибочно принимают за узкое место приложения.
Предположим, при очередной ступени нагрузка на генератор достигает высокого уровня, а CPU, очереди и время обработки на сервере ещё далеки от насыщения. В модели с виртуальными пользователями генератор начинает медленнее запускать следующие итерации; в модели с заданной скоростью поступления он может не успевать поддерживать требуемый темп.
В результате фактическая нагрузка на сервис становится ниже заявленной или начинает поступать с нарушениями расписания. Задержки, измеренные генератором, могут расти из-за ожидания на стороне клиента, а вывод о производительности приложения окажется недостоверным.
Сначала нужно установить, что именно насыщено. Одного показателя CPU недостаточно: причиной могут быть пользовательское или системное время, ожидание ввода-вывода, очередь выполнения, сетевой интерфейс, пул соединений, обработка TLS, сериализация ответов или чрезмерный сбор результатов.
Нужно сопоставить несколько групп данных:
Если генератор ограничен, его клиентская задержка обычно растёт раньше серверной, а фактическая скорость нагрузки перестаёт следовать заданной. При добавлении второго генератора фактическая нагрузка и нагрузка на приложение должны увеличиться; если приложение после этого достигает собственного насыщения, прежний предел был пределом стенда.
Нужно учитывать общие ресурсы. Несколько генераторов не устранят ограничение общего канала, балансировщика, NAT, прокси или сервера, на котором они размещены. Также высокий CPU генератора не доказывает его неспособность: часть CPU может приходиться на полезную обработку, а реальное ограничение может находиться в сети или в соединениях.
Практически применяют запас по ресурсам генератора, горизонтальное распределение нагрузки и отдельную проверку его максимальной производительности. Полезно уменьшать избыточное логирование и хранение тел ответов, но только если это не меняет измеряемый сценарий. Такой компромисс повышает ёмкость стенда, однако может скрыть проблему, если именно клиентская обработка является частью реального пользовательского пути.
Команда проверяла сервис оформления заказа ступенями. На очередной ступени генератор достигал почти полного CPU, его фактическая скорость перестала расти, а сервер приложения сохранял запас по CPU и не показывал роста времени обработки. При этом отчёт генератора показывал увеличение полной задержки.
Рассматривались три варианта. Можно было продолжить тест на одном генераторе, но тогда измерялась бы его перегрузка. Можно было снизить детализацию логов, что быстро высвободило ресурсы, но существовал риск изменить профиль клиента. Наконец, можно было добавить генераторы и проверить стенд на масштабирование.
Выбрали третий вариант: распределили виртуальных пользователей, сохранили исходный сценарий и проверили суммарную фактическую скорость. После добавления генераторов нагрузка на приложение выросла, а его задержки начали увеличиваться только на следующей ступени; именно эту ступень использовали для анализа производительности сервиса. Первоначальный результат признали ограниченным генератором и не включили в оценку предела приложения.
Ответ: Нет. Это может убрать перегрузку, но одновременно уменьшит фактическую нагрузку на приложение. Результат станет корректнее только для меньшего уровня нагрузки, а исходную ступень он не заменит. Чтобы исследовать исходный уровень, нужен генератор с запасом или несколько генераторов, способных поддерживать требуемый темп.
Ответ: Нужно анализировать сетевой интерфейс и ошибки передачи на генераторе, потери и задержки сети, объём трафика, число соединений и серверные признаки получения запросов. При сетевом ограничении CPU генератора может оставаться умеренным, но фактический поток запросов и ответов перестаёт расти. Если добавление генераторов не увеличивает суммарную нагрузку, а общий канал уже насыщен, масштабирование самих генераторов проблему не решит.
Ответ: Да, особенно при некорректной реализации модели нагрузки или учёта времени. Если генератор не создаёт запланированные запросы и в отчёт попадают только успешно начатые операции, перегрузка может скрыть часть ожиданий и искусственно улучшить показатели. Поэтому необходимо проверять полноту выборки, пропущенные итерации и интервалы между фактическими отправками, а не доверять только средней задержке завершённых запросов.