Сценарий: в production 90% запросов — поиск, 10% — оформление заказа, но тест запускает их поровну. Какой вывод о результатах будет корректным?
Результаты такого теста описывают искусственный профиль с равной долей операций, а не реальную production-нагрузку. По ним нельзя напрямую судить о производительности системы при фактическом соотношении 90/10: более тяжёлая операция может непропорционально исказить задержки, пропускную способность и загрузку ресурсов.
Модели нагрузки появились как способ связать результаты испытаний с реальным режимом использования системы. Одной интенсивности запросов недостаточно: разные операции могут потреблять различное количество CPU, памяти, сетевого трафика, соединений с базой данных и других ресурсов.
Поэтому нагрузочный профиль обычно строят на основе наблюдаемой частоты бизнес-операций. Это позволяет проверять не абстрактную способность сервиса обрабатывать запросы, а его поведение в условиях, близких к эксплуатации.
При равных долях поиск и оформление заказа тест в пять раз увеличивает долю оформления относительно production-профиля. Если оформление заказа тяжелее поиска, система будет выглядеть менее производительной, чем в реальности; если поиск создаёт необычную нагрузку на кэш или отдельный ресурс, возможен обратный эффект.
Искажаются не только средние значения. Меняются очереди, конкуренция за общие ресурсы, распределение задержек, доля ошибок и точка насыщения. В результате команда может преждевременно масштабировать систему либо пропустить проблему, возникающую именно при реальном составе трафика.
Сначала фиксируют операционный профиль: долю каждого сценария, интенсивность, параметры запросов, размер ответов, последовательности действий пользователя и долю ошибок или повторов, если они являются частью реального поведения. Затем проверяют, что генератор воспроизводит эти доли не только в плане, но и среди фактически завершённых операций.
Для профиля 90/10 каждая сотня операций должна в среднем содержать около 90 поисков и 10 оформлений. При этом важно учитывать статистические колебания: на коротком тесте фактическая доля может заметно отличаться от целевой, поэтому контролируют доверительные интервалы или запускают тест достаточно долго.
Нельзя автоматически считать production-профиль единственно правильным. Равная доля может быть оправдана для отдельного capacity-теста оформления заказа или для анализа его изолированного предела, но такой результат нужно явно маркировать как относящийся к специальному профилю, а не к обычной эксплуатации.
Полезно проводить как минимум два сравнения: тест с production-миксом для оценки поведения системы в штатном режиме и отдельные тесты тяжёлых сценариев для поиска их индивидуального предела. Для итогового SLA метрики следует считать по всему пользовательскому трафику и отдельно по критичным операциям, чтобы общий показатель не скрыл деградацию конкретного сценария.
Команда тестировала интернет-магазин, используя равные доли поиска и оформления заказа. При такой модели p95 общей задержки превысил SLA, а пул соединений с базой данных быстро исчерпывался. Рассматривались два варианта: увеличить ресурсы базы данных либо сначала восстановить реальный профиль нагрузки.
Масштабирование базы сразу дало бы более дорогой тест, но не показало бы, насколько проблема вызвана искусственным избытком оформления заказов. Команда выбрала production-микс 90/10, добавила отдельный стресс-тест оформления и сохранила раздельные метрики по сценариям.
В результате общий p95 при реальном профиле уложился в SLA, однако отдельный тест оформления выявил узкий SQL-запрос. Такой результат позволил не масштабировать всю базу без необходимости, а оптимизировать конкретную операцию и подтвердить её предел отдельным испытанием.
Нет. Важны также временная структура нагрузки, пользовательские последовательности, параметры запросов и корреляции между действиями. Два теста с одинаковым соотношением 90/10 могут давать разные результаты, если в одном оформление равномерно распределено во времени, а в другом возникает вместе с пиками поиска.
Обычно нельзя. Ресурсы разделяются между сценариями нелинейно: операции могут конкурировать за общий пул соединений, кэш, блокировки, очереди или пропускную способность сети. Поэтому корректнее выполнить тест с нужным миксом либо построить модель, подтверждённую отдельными измерениями взаимодействия сценариев.
Один усреднённый профиль может скрыть важные режимы. Нужно выделить характерные окна, например обычную нагрузку, пик и редкие события, затем проверить каждый профиль отдельно. Если состав операций влияет на узкое место, итоговые выводы следует делать по каждому режиму, а не только по среднему за сутки.