Рассмотрите нагрузочный тест, в котором генератор и тестируемый сервис работают на одном физическом хосте. Как это может исказить поиск узкого места?
Совместный хостинг генератора и тестируемого сервиса нарушает изоляцию эксперимента: они конкурируют за процессорное время, память, пропускную способность памяти, сетевой стек и другие ресурсы. Поэтому рост задержки или падение пропускной способности нельзя автоматически связать с сервисом — причиной может быть сам генератор либо взаимное влияние процессов.
Нагрузочные тесты возникли как способ измерять поведение системы под контролируемым потоком запросов, а не просто проверять функциональную корректность. Для такого измерения важно отделить ограничения тестируемой системы от ограничений инструмента, сети и среды выполнения.
Именно поэтому в производительных испытаниях стремятся изолировать генераторы нагрузки и систему под тестом. Иначе эксперимент измеряет не только производительность сервиса, но и свойства совместно используемой инфраструктуры.
Генератор нагрузки сам выполняет работу: создаёт операции, устанавливает или переиспользует соединения, сериализует запросы, принимает ответы, считает метрики и планирует следующий запрос. При совместном размещении эта работа конкурирует с обработкой запросов сервисом.
Искажение может проявляться по-разному: генератор перестаёт поддерживать целевой поток, задержка планирования запросов увеличивается, растёт конкуренция за CPU или ухудшается работа сетевого стека. В результате наблюдаемая задержка может стать выше реальной задержки сервиса, а достигнутая пропускная способность — ниже его возможностей.
Сначала нужно проверить, способен ли генератор поддерживать требуемую модель нагрузки без ограничений. Для этого анализируют его CPU по ядрам, задержки планирования, пропускную способность сети, число открытых соединений, очереди внутри инструмента и расхождение между запланированной и фактически отправленной нагрузкой.
Средняя загрузка CPU недостаточна: одно перегруженное ядро, системные потоки, прерывания или конкуренция за память могут ограничивать генератор при низком среднем значении. Также следует учитывать, что совместное размещение может менять кэширование, планирование потоков и сетевой путь, поэтому низкая утилизация отдельных ресурсов не доказывает отсутствие влияния.
Надёжный подход — вынести генератор на отдельные хосты или использовать отдельные узлы для генерации и обработки трафика. Затем повторить тест при той же модели нагрузки и сравнить не только RPS и p95, но и фактически отправленный поток, ошибки, распределение задержек и ресурсные метрики обеих сторон.
Если разнесение изменило результаты, прежний тест нельзя использовать для точного вывода о пределе сервиса. При этом отдельный генератор не устраняет все искажения: нужно проверить сетевой путь, лимиты соединений, виртуализацию, синхронизацию времени и достаточность самого генератора.
Команда разместила генератор и сервис на одном хосте. При увеличении нагрузки p95 рос, а CPU каждого процесса в среднем оставался умеренным. Рассматривались три варианта: увеличить число потоков генератора, оптимизировать сервис или разнести компоненты.
Увеличение числа потоков было дешёвым, но могло усилить конкуренцию за ресурсы и не доказало бы источник ограничения. Оптимизация сервиса до подтверждения причины создала бы риск исправлять артефакт измерения. Разнесение компонентов потребовало дополнительного узла и настройки сети, зато позволило отделить ограничения генератора от ограничений сервиса.
После повторного теста на раздельных хостах сравнили фактически достигнутый поток, задержки и метрики ресурсов. Такой эксперимент дал основание считать обнаруженное ограничение свойством сервиса только в той мере, в какой оно сохранялось после устранения конкуренции за ресурсы генератора.
1. Достаточно ли вынести генератор на другой виртуальный сервер?
Не обязательно. Виртуальные серверы могут делить физические CPU, память, сетевые устройства и другие ресурсы, поэтому конкуренция может сохраниться на уровне гипервизора. Нужно контролировать не только логическое размещение, но и фактическую изоляцию, включая показатель времени ожидания физического CPU и сетевую топологию.
2. Почему низкий средний CPU генератора не доказывает, что он не ограничивает тест?
Среднее значение скрывает дисбаланс по ядрам и короткие пики. Один поток планирования, обработка событий или сетевые прерывания могут упереться в одно ядро, тогда как остальные ядра будут простаивать. Поэтому проверяют показатели по ядрам, задержки генерации, фактический темп отправки и соответствие целевой модели нагрузки.
3. Можно ли считать результаты корректными, если при совместном размещении генератор отправляет заявленный RPS?
Сам по себе заявленный RPS недостаточен. Генератор может отправлять нужное число запросов, но добавлять задержку до отправки, конкурировать с сервисом за ресурсы или менять сетевое поведение. Корректность повышается, если раздельные контрольные прогоны показывают отсутствие влияния генератора, однако для критичных выводов предпочтительна физическая или подтверждённая инфраструктурная изоляция.