Перед каждым заметным релизом у меня в голове звучит один и тот же вопрос: выдержит или упадёт? Нагрузочное тестирование — это способ ответить на него не ощущениями, а цифрами. Но цифры сами по себе ничего не стоят, если тест запущен не в тот момент, не на той среде и не с теми ожиданиями.
Эта статья — первая в серии. Дальше разберём локальную установку k6, разбиение сценариев, InfluxDB для хранения метрик и, самое важное для меня, чтение графиков так, чтобы из них рождались решения, а не красивые скриншоты в отчёте. Сейчас — про когда нагрузка вообще оправдана и что нужно иметь до первого прогона.
Что нагрузочное тестирование делает и чего не делает
Нагрузочное тестирование имитирует трафик: виртуальные пользователи или поток запросов бьют в ваш сервис по заданному сценарию. На выходе — метрики: время ответа и его процентиль (p50, p95, p99), пропускная способность (RPS), доля ошибок, иногда поведение CPU и памяти на стороне инфраструктуры. Терминологическая оговорка, потому что её часто замалчивают: p95 — это не «задержка» и не отдельная метрика, а процентиль распределения. Запись «p95 = 400 мс» читается так: 95% запросов обработались за 400 мс или быстрее, а оставшиеся 5% — медленнее. И всегда уточняйте, распределение чего вы считаете: по умолчанию в k6 это полная длительность запроса (http_req_duration), но рядом живут и время до первого байта (http_req_waiting), и время получения тела ответа (http_req_receiving) — у каждой метрики свои p50/p95/p99, и путать их между собой нельзя.
Оно не заменяет функциональные тесты. Сценарий может быть «зелёным» по статус-кодам и при этом ловить таймауты под нагрузкой. Оно не гарантирует поведение в проде один в один: вы всегда тестируете модель реальности — упрощённые данные, другой объём кэша, иной профиль клиентов. И оно не лечит архитектуру: если узкое место — синхронный вызов в чужой API без пула, тест лишь покажет, где именно больно.
Зато нагрузка отлично отвечает на практические вопросы: при каком RPS начинает расти p95? держится ли сервис 30 минут под пиком? что будет, если трафик вырастет вдвое за минуту? есть ли утечки соединений или памяти на длинной дистанции?
Когда нагрузку имеет смысл закладывать в процесс
Я склонен планировать НТ, если выполняется хотя бы одно из условий ниже.
Есть ожидаемый или договорной SLA/SLO — «p95 не хуже 300 мс при 500 RPS» без измерения остаётся пожеланием.
Меняется что-то, что бьёт по производительности: новый эндпоинт, тяжёлый запрос в БД, смена кэша, миграция на другой runtime, включение очередей.
Готовится событие с пиком — акция, рассылка, интеграция с внешней системой, которая внезапно начнёт слать вам вдесятеро больше запросов.
Уже были инциденты «под нагрузкой» — 502 при деплое, connection pool exhausted, деградация после N минут. Повторить проблему контролируемо дешевле, чем в проде в пятницу вечером.
Нужно сравнить варианты — два способа пагинации, с кэшем и без, старая и новая версия сервиса на одной среде.
Обратная сторона: если продукт на стадии «два пользователя и MVP», а цель — проверить бизнес-гипотезу, полноценный стенд с Grafana и Influx может подождать. Достаточно дымового прогона на десяток VU, чтобы убедиться, что критический путь не падает мгновенно.
Когда можно не раздувать НТ
Честный список ситуаций, где я не трачу неделю на стенд.
Нет стабильной тестовой среды, близкой к проду по конфигурации — результаты будут спорить с реальностью, а команда спорить друг с другом.
Нет согласованных целей: «просто погонять» почти всегда заканчивается фразой «ну вроде норм» без порогов и без действий.
Единственный генератор — ноутбук через домашний Wi‑Fi. Сеть и фоновые процессы искажают задержки сильнее, чем кажется. Об этом подробнее в следующей статье про установку и инфраструктуру.
Команда не готова чинить найденное до релиза — тогда НТ превращается в ритуал ради галочки.
Виды прогонов: не всё называется «нагрузкой»
Одно слово «load test» в разговорах смешивает разные задачи. Я разделяю их так — и в k6 под каждый тип потом будет свой профиль нагрузки.
| Вид прогона | Профиль нагрузки | Что проверяем |
|---|---|---|
| Smoke | Мало VU, коротко, 1–5 минут | Сценарий вообще выполняется, thresholds не красные, метрики пишутся |
| Load | Штатный уровень или ближайший ожидаемый пик | Стабильность p95/p99 и доля ошибок на всём окне прогона |
| Stress | Нагрузка выше целевой, пока система не деградирует | Запас прочности и поведение при перегрузе: очереди, таймауты, circuit breaker, graceful degradation или жёсткое падение |
| Spike | Резкий скачок трафика за секунды | Cold start, autoscaling с лагом, исчерпание пула соединений за один всплеск |
| Soak | Умеренная нагрузка, но долгая — часы | Утечки памяти, рост latency от фрагментации, накопление фоновых задач, проблемы с ротацией логов и диском |
Smoke я запускаю после каждого изменения скрипта и перед каждым «большим» прогоном — это самый дешёвый способ поймать сломанный сценарий до того, как он потратит час стенда.
Что подготовить до первого запуска k6
Инструмент — это последний шаг. Сначала я фиксирую контекст на одной странице.
Цель прогона — одна формулировка: «проверить, что checkout выдерживает 200 RPS с p95 < 400 мс».
Границы системы — что входит в тест (только API gateway или весь путь до БД), что мокаем, что оставляем боевым. По возможности все внешние интеграции лучше мокировать: так тест измеряет вашу систему, а не чужой API с его лимитами. Как и чем поднимать моки — подробно разберу в части про инфраструктуру.
Тестовые данные — пользователи, токены, каталог. Без данных сценарий часто «летает», потому что бьёт в 404 или пустой кэш.
Среда — отдельный стенд, по возможности тот же регион/ДЦ, что и генератор нагрузки. Версии сервисов и лимиты (rate limit, WAF) должны быть известны.
Мониторинг — хотя бы метрики приложения и БД параллельно с k6. Иначе вы видите «p95 вырос», но не видите «диск на 99%» — и не понимаете, что на самом деле произошло.
Критерии успеха — thresholds в k6 или явная таблица: метрика, порог, что делаем при провале.
Если этого нет, первый прогон всё равно полезен как обучение. Но для решения «выпускаем или нет» — слабоват.
По итогу
Нагрузочное тестирование оправдано, когда у вас есть измеримая цель, среда, на которой можно доверять цифрам, и готовность реагировать на результат.
Без этого лучше начать с малого smoke и договориться о SLO, чем строить красивый стенд ради одного прогона «для успокоения».
В следующей части поставим k6 на машину генератора, соберём первый осмысленный сценарий и обсудим, откуда брать нагрузку, чтобы сеть не врала.
Обсуждение
Комментариев пока нет — начните тему.