У стресс-теста нет одной правильной длительности
Вопрос о длительности теста кажется простым только на первый взгляд. На практике нельзя выбрать одно универсальное число минут и считать его правильным для любого проекта. Короткий smoke-тест отвечает на один класс вопросов, ступенчатый ramp-тест на другой, а длинный soak-тест на третий. Поэтому правильная продолжительность всегда определяется не традицией команды, а формулировкой гипотезы.
Если вы хотите проверить, жив ли маршрут после конфигурационного изменения, достаточно короткого контролируемого прогона. Если задача — понять, где начинается деградация при росте нагрузки, нужен поэтапный ramp с паузами для наблюдения. Если же вас беспокоят memory leaks, накопление очередей, медленный scale-in или долгие хвосты после пика, нужен уже более длинный soak. Пытаться решить все эти задачи одной длиной бессмысленно.
Английская версия этой темы находится в How long should stress test run, но практическая ценность появляется только тогда, когда длина теста увязана с конкретным типом сервиса: API, веб, CDN-path или игровой сервер.
Когда выбирать smoke, ramp или soak
Smoke-прогон нужен для быстрой проверки базовой работоспособности сценария и мониторинга. Обычно он короткий и аккуратный: задача не в том, чтобы найти максимум, а в том, чтобы убедиться, что вы вообще измеряете то, что хотели измерять. Это особенно полезно перед большим авторизованным окном или перед переходом к более серьёзной нагрузке.
Ramp-тест полезен, когда нужно найти порог деградации. Нагрузка растёт ступенями, а команда наблюдает, при каком уровне начинают портиться latency, error rate, очереди и recovery. Для большинства инженерных задач именно такой формат даёт самый практический вывод. Он хорошо сочетается со сценариями вроде нагрузочного тестирования API перед релизом или подготовки сайта к распродаже.
Soak-тест нужен, если есть риск медленной деградации во времени: утечки памяти, накопление фоновых задач, медленный дренаж очередей, проблемы с длительными сессиями или отложенные эффекты на базе. Такой прогон часто менее эффектен визуально, но именно он помогает поймать те проблемы, которые не проявляются на коротком пике.
Длительность зависит от типа системы и риска
У API и веб-приложений короткие и средние тесты часто дают много пользы, потому что проблемы в маршрутах, пуле соединений и rate limiting видны довольно быстро. У CDN-сценариев важно дать время на стабилизацию кэша и посмотреть, как ведут себя miss-path. У игровых серверов часть проблем видна почти мгновенно по tickrate и latency, но другая часть проявляется только на длительной игровой сессии. Значит, одной цифры времени для всех систем не существует.
Полезно также учитывать стоимость ошибки. Если вы готовите обычный внутренний релиз, может хватить короткой репетиции. Если речь о публичном запуске, маркетинговом пике или инфраструктуре с дорогими последствиями простоя, тестовое окно почти всегда должно включать не только сам пик, но и наблюдение до него и после него. То есть длина теста — это не только минуты активной нагрузки, но и время на baseline и cool-down.
Связать это с выбором тарифа помогает страница /pricing: вы смотрите на max time не как на красивую цифру, а как на возможность честно выполнить именно тот тип прогона, который вам нужен.
Почему важно планировать не только старт, но и остановку
Слишком длинный тест без заранее заданных критериев остановки опаснее, чем короткий, но хорошо управляемый. Если вы не знаете, при каком уровне p95, error rate, saturation базы или побочном эффекте тест должен быть остановлен, длительность перестаёт быть инженерным параметром и становится источником риска. Правильный прогон всегда имеет не только start, но и понятный abort.
Не менее важен cool-down после stop. Многие команды заканчивают тест в ту же секунду, когда прекращается подача нагрузки, и теряют ценные наблюдения. Между тем реальная устойчивость часто определяется тем, насколько быстро разгружаются очереди, возвращается нормальная latency и успокаивается autoscaling. Иногда именно после остановки становится ясно, выдержала ли система пик по-настоящему.
Все такие запуски должны происходить в авторизованном режиме и на подтверждённых целях. Прежде чем запускать длинные или регулярные проверки, убедитесь, что рабочий процесс укладывается в правила /legal и что у команды есть выделенный доступ через /register.
В advisory явно укажите, кто жмёт stop и какие пороги p95/error rate/saturation считаются красными. Без имени владельца abort длительность превращается в лотерею. После остановки оставьте наблюдателя на cool-down — это дешёвые минуты с дорогими findings. Правила платформы: /legal.
Практическое правило выбора длительности
Если нужно одно короткое правило, оно звучит так: тест должен длиться ровно столько, сколько нужно, чтобы получить сигнал по вашей гипотезе, и ни минутой дольше. Не пытайтесь заменить качественный дизайн сценария бесконечным временем. Долгий тест без ясного вопроса лишь расходует окно и создаёт больше шума в мониторинге.
Поэтому перед запуском ответьте на три вопроса. Что я пытаюсь доказать? За какое время эта проблема вообще успевает проявиться? Какие признаки подскажут, что мы уже получили достаточно данных? После этого длительность обычно становится понятной. А если не становится, значит гипотеза ещё недостаточно ясна, и стоит сначала доработать её, а не спорить о минутах.
На практике зрелые команды комбинируют несколько форматов: короткий smoke, затем ramp, а при необходимости отдельный soak. Такой набор почти всегда полезнее одной «магической» продолжительности для всех задач.
Зафиксируйте в шаблоне команды три стандартных профиля длительности (smoke / ramp / soak) с рекомендуемыми минутами и обязательным cool-down. Новым участникам не придётся изобретать тайминги под давлением. Связка с тарифом — на /pricing; EN-пара — how long should a stress test run; регистрация — /register.