non-functionaltoolsperformance

JMeter: пошагово для первого нагрузочного теста

Нужно понять, выдержит ли твой API 1000 одновременных пользователей? JMeter — Java-инструмент с 2002 года, до сих пор стандарт для нагрузочного тестирования. Гайд от нуля до первого результата.

Установка

Скачать с jmeter.apache.org. Распаковать. Запустить bin/jmeter (Mac/Linux) или bin/jmeter.bat (Windows). Нужна Java 8+.

Базовые понятия

— Thread Group — группа «виртуальных пользователей». Сколько потоков → столько параллельных юзеров. — Sampler — одно действие. Чаще всего HTTP Request. — Listener — что показать результат. Aggregate Report — таблица с метриками, Summary Report — компактная сводка.

Минимальный тест

  1. Test Plan → правый клик → Add → Threads → Thread Group.

    • Number of threads: 100 (юзеров).
    • Ramp-up period: 60 (за 60 сек выйдут все 100).
    • Loop Count: 10 (каждый сделает 10 запросов).

  2. Thread Group → правый клик → Add → Sampler → HTTP Request.

    • Method: GET.
    • Path: /api/users/1.
    • Server: api.example.com.
    • Port: 443.
    • Protocol: https.

  3. HTTP Request → правый клик → Add → Listener → Aggregate Report.

  4. Сохрани план как .jmx файл (это XML, можно положить в git).

  5. Запусти — Ctrl+R.

Что смотреть в результатах

В Aggregate Report:

— Average — среднее время ответа. Если >1000ms — bottleneck. — Median — медиана. Обычно ниже average (выбросы тянут average вверх). — 90% Line — 90-й процентиль. Самое важное число для UX — «10% юзеров получат хуже». — Throughput — запросов в секунду. Это реальная пропускная способность. — Error % — процент 500/timeout. Должно быть 0 на разумной нагрузке.

Если на 100 параллельных юзеров 90% Line = 500ms, а на 200 — 90% Line = 3000ms — нашёл точку насыщения.

Реалистичные сценарии

Один GET — это не нагрузочный тест. Реальный:

Thread Group (100 users)
├── HTTP Login
│   └── Extract token (Post Processor: JSON Extractor)
├── HTTP Request: /api/products (с заголовком Auth)
├── HTTP Request: /api/cart/add
├── HTTP Request: /api/checkout
└── Think Time (Timer): 2-5 секунд между шагами

Think Time обязателен. Реальный юзер не отправляет запросы каждые 5 мс — у него есть пауза между действиями. Без Think Time ты тестируешь не нагрузку, а DDoS.

Параметризация

Все 100 юзеров логинятся одним и тем же email? Это не realtime-тест. Параметризуй через CSV Data Set Config:

csv: users.csv
email,password
[email protected],pass1
[email protected],pass2
...

Каждый поток берёт свою строку.

Headless режим (для CI)

jmeter -n -t test_plan.jmx -l results.jtl -e -o html_report/

-n non-GUI, -t test plan, -l results CSV, -e -o сгенерировать HTML-отчёт.

Это стандартный путь в CI/CD pipeline.

Альтернативы (если JMeter не подошёл)

— k6 — современный, тесты на JavaScript, дружелюбнее CI. См. мой пост про сравнение хоть и про другое — но та же категория «выбора тула». — Locust — Python, отлично если команда уже на Python. — Gatling — Scala, hardcore-производительность.

Чек-лист QA

✅ Нагрузка симулирует реальный сценарий, не один endpoint.

✅ Включён Think Time между запросами.

✅ Параметризация юзеров через CSV.

✅ Запуск в headless из CI с HTML-отчётом.

✅ Точка насыщения определена — знаешь сколько RPS ваш сервер выдерживает.

✅ Тест воспроизводим — .jmx файл в git, кто угодно может перезапустить.

Подробнее: Apache JMeter docs, k6 docs.