Команда хочет определить максимальную нагрузку, при которой сервис сохраняет заданный SLA, а не просто довести его до отказа. Какой тип теста для этого нужен?
Нужен capacity-тест — тест определения предельной устойчивой производительности. Его цель — найти максимальную нагрузку, при которой сервис сохраняет заданные показатели задержки, ошибок и пропускной способности в течение согласованного периода.
Это отличается от stress-теста, который исследует поведение за пределами расчетной мощности, и от soak-теста, который проверяет деградацию при длительной работе.
Разделение типов нагрузочных тестов появилось из-за разных эксплуатационных вопросов, которые нельзя надежно решить одним прогоном. Бизнесу важно знать не только момент отказа системы, но и безопасную рабочую границу, а также способность сохранять характеристики в течение длительного времени.
Поэтому нагрузочные проверки разделяют по цели: поиск рабочей мощности, исследование поведения при перегрузке и выявление долговременной деградации. Такое разделение делает критерии успеха и интерпретацию результатов однозначнее.
Если команда доводит систему до первого отказа и называет полученную точку ее производительностью, результат может быть непригоден для планирования. Перед отказом уже могут нарушаться SLA, расти очередь, увеличиваться доля ошибок или ухудшаться пользовательские задержки.
Обратная ошибка также опасна: короткий capacity-тест может показать соответствие SLA, хотя через несколько часов проявятся утечка памяти, исчерпание пула соединений или накопление очередей. Поэтому тип теста выбирают по проверяемому риску, а не по привычному сценарию запуска.
В capacity-тесте нагрузку обычно повышают ступенчато или плавно. На каждом уровне выдерживают период стабилизации и измеряют пропускную способность, распределение задержек, долю ошибок и состояние ресурсов.
Искомая точка — не первая техническая возможность обработать запросы, а наибольший уровень нагрузки, при котором одновременно выполняются условия приемки. Например, p95 должен оставаться ниже порога, доля ошибок — в допустимых пределах, а пропускная способность — соответствовать целевому уровню.
Stress-тест продолжают за найденную рабочую границу. Он отвечает на другой вопрос: как система деградирует, какие ограничения срабатывают первыми, сохраняется ли управляемость и как происходит восстановление после снижения нагрузки.
Soak-тест выполняют при длительной, обычно заранее выбранной рабочей нагрузке. Его критериями становятся не только текущие SLA, но и отсутствие постепенного ухудшения: роста потребления памяти, увеличения очередей, снижения пропускной способности или накопления ошибок.
У каждого подхода есть ограничения. Capacity-тест зависит от профиля операций, размера данных, кэшей и модели нагрузки; найденная граница не универсальна для любого трафика. Stress-тест может создать риск для общей среды, а soak-тест требует длительного времени и контроля изменений окружения.
Сервис должен стабильно обрабатывать 800 операций в секунду при p95 не выше 300 миллисекунд. Команда рассмотрела три варианта: сразу довести нагрузку до отказа, постепенно искать рабочую границу или оставить 800 операций в секунду на 24 часа.
Первый вариант удобен для быстрой оценки предела, но не показывает безопасную эксплуатационную мощность. Третий вариант хорошо выявляет долговременную деградацию, однако не отвечает на вопрос, выдерживает ли сервис 900 или 1000 операций в секунду.
Выбрали ступенчатый capacity-тест: нагрузку увеличивали небольшими уровнями, на каждом уровне ждали стабилизации и проверяли SLA. Максимальным приняли уровень 900 операций в секунду, потому что на 1000 p95 превысил порог и начала расти очередь запросов. После этого отдельно запланировали soak-тест на 900 и stress-тест выше найденной границы.
Нет. Максимальный RPS может достигаться уже при нарушенном SLA, высокой доле ошибок или нестабильных задержках. Capacity — это максимальная нагрузка, удовлетворяющая всем критериям приемки, а не просто пик пропускной способности.
Без периода стабилизации измерения могут отражать переходный процесс: прогрев кэшей, заполнение пулов и очередей, автоскейлинг или накопление фоновой работы. Тогда граница мощности будет зависеть от скорости разгона теста, а не только от характеристик системы.
Одинаковый RPS может создавать разную нагрузку: операции отличаются объемом данных, долей записей, стоимостью запросов к базе, размером ответа и вероятностью попадания в кэш. Поэтому capacity нужно определять для реалистичного профиля нагрузки либо отдельно измерять для нескольких значимых профилей.