Функциональные тесты отвечают на вопрос «работает ли». Нагрузочные — на вопросы, которые всплывают позже и больнее: сколько пользователей выдержит сервис, где он сломается и что произойдёт при пике. Отвечать на них в проде — дорого; для этого и существует нагрузочное тестирование.
Виды нагрузки: четыре вопроса — четыре теста
- Load test — «держим ли ожидаемую нагрузку?»: подаём плановый трафик (например, 200 запросов в секунду) и смотрим, укладываемся ли в целевую латентность.
- Stress test — «где предел и как ломаемся?»: наращиваем нагрузку до деградации. Важен не только предел, но и характер отказа: плавное замедление или лавина ошибок и падение.
- Soak test — «выживем ли за ночь?»: умеренная нагрузка часами. Ловит то, что не видно за десять минут: утечки памяти, исчерпание соединений, распухание кэшей.
- Spike test — «переживём ли пик?»: резкий скачок (реклама вышла, рассылка ушла) и возврат к норме. Проверяет автомасштабирование и очереди.
Метрики: что измерять
Пропускная способность — запросов в секунду (RPS/TPS). Ошибки — доля не-2xx и таймаутов. И главное — латентность перцентилями:
- p50 (медиана) — типичный пользователь;
- p95/p99 — хвост: каждый двадцатый/сотый запрос медленнее этого значения.
Среднее арифметическое — худшая метрика латентности: среднее 80 мс может скрывать p99 в 4 секунды, а страдающие 1% пользователей — это на большом сервисе тысячи людей. SLA формулируют перцентилями: «p99 < 300 мс при 500 RPS, ошибок < 0.1%».
Смотрите на связку: с ростом нагрузки RPS растёт линейно, потом выходит на полку, а латентность у полки взлетает — это и есть предел системы (сатурация).
Инструменты
| JMeter | Gatling | k6 | |
|---|---|---|---|
| Сценарии | GUI + XML | код на Scala/Java DSL | код на JavaScript |
| Сильная сторона | зрелость, море плагинов, любые протоколы | эффективность, отчёты из коробки | простота, CI-дружелюбие, лёгкий бинарь |
| Слабая сторона | тяжёлые сценарии в XML, дорогие потоки | порог входа в DSL | меньше протоколов вне HTTP |
| Кому подходит | команды с историей на нём, не-HTTP протоколы | JVM-команды, сценарии как код | новые проекты, нагрузка в pipeline |
Практическое правило: для нового проекта с HTTP/gRPC начинайте с k6 или Gatling — сценарии живут в git и гоняются в CI. JMeter выбирают за экзотические протоколы и накопленную экспертизу.
Методика: пять шагов
- Цель из SLA: «p99 < 300 мс при 500 RPS» — без цели тест не интерпретировать.
- Реалистичный сценарий: микс операций как в проде (95% чтение / 5% запись, а не однородный GET), реалистичные данные, прогрев кэшей отдельным этапом.
- Стенд, похожий на прод: те же лимиты CPU/памяти, та же база с прод-объёмом данных. Тест против пустой базы на мощном стенде измеряет ничего.
- Генератор — не узкое место: нагрузку подают с отдельной машины (не с ноутбука через VPN) и проверяют, что упирается система, а не генератор.
- Анализ у полки: метрики приложения и инфраструктуры (мониторинг в момент теста) — CPU, пул соединений БД, GC-паузы: предел всегда во что-то конкретное упирается.
Типичные ошибки
- Смотреть на среднее вместо перцентилей — см. выше.
- Мерить без прогрева: первые минуты JVM-сервис прогревает JIT и кэши, эти цифры не о проде.
- Игнорировать coordinated omission: если генератор ждёт ответа перед следующим запросом, он сам замедляется вместе с сервисом и занижает хвост латентности. Инструменты с открытой моделью нагрузки (k6 arrival rate, Gatling) от этого защищают.
- Однократный запуск: результат без повторения — случайность, а не измерение.
Коротко
- Четыре вида: load — плановая нагрузка, stress — поиск предела, soak — часы работы (утечки), spike — резкий пик.
- Метрики: RPS, доля ошибок и латентность перцентилями (p50/p95/p99); среднее — вводит в заблуждение, SLA формулируют перцентилями.
- Инструменты: k6 — сценарии на JS и CI; Gatling — код и отчёты для JVM-команд; JMeter — зрелость и не-HTTP протоколы.
- Методика: цель из SLA → реалистичный сценарий → прод-подобный стенд → генератор не узкое место → анализ метрик у предела.
- Главные грабли: среднее вместо перцентилей, тест без прогрева, coordinated omission, вывод по одному прогону.
Что почитать дальше
- Пирамида тестирования — где нагрузочные тесты живут среди остальных.
- Наблюдаемость — без метрик приложения анализ нагрузочного теста слеп.
- Балансировка нагрузки — что стоит между пользователем и вашим пределом.