P
perfscale

Ядро

Нагрузочное тестирование с JMeter

perfscale запускает ваши существующие тест-планы JMeter (.jmx) в headless-режиме и сводит результаты в тот же поток логов в реальном времени и k6-совместимый формат сводки, что и все остальные движки. Ничего переписывать не нужно: возьмите уже имеющийся план, укажите на него perfscale и получите живой вывод плюс машиночитаемую сводку, которую можно сравнивать с прогонами k6, locust и нативного движка.

perfscale run --jmeter plan.jmx

Предварительные требования

На машине, где выполняется тест, должна быть установлена JMeter — perfscale оборачивает её, а не встраивает:

jmeter --version   # must be on PATH (requires a JRE)

Если бинарный файл не найден, запуск быстро завершается с ошибкой jmeter not found in PATH — install from https://jmeter.apache.org/download_jmeter.cgi (requires a JRE). На агентах PerfScale Cloud dev-образ docker уже содержит JRE с JMeter 5.6.3.

Как проходит прогон

perfscale запускает план в non-GUI-режиме и стримит всё в реальном времени:

jmeter -n -t <plan.jmx>
  • JMeter полностью определяет форму нагрузки. Thread groups, ramp-up, таймеры и пропускная способность — всё берётся из плана. perfscale не передаёт никаких -J-свойств, а конфигурация запуска perfscale (vus, duration, stages:) не применяется — план и есть конфигурация.
  • Живой вывод. Собственные stdout/stderr JMeter стримятся во время прогона, так же как вывод k6 или locust.
  • Код выхода. JMeter завершается с ненулевым кодом при ошибках плана или запуска; падения сэмплов внутри плана не меняют код выхода, если сам план на них не реагирует. В CI код выхода — это ваш гейт здоровья плана.

Транслированная сводка

После завершения процесса perfscale захватывает финальную консольную строку JMeter (summary = N in HH:MM:SS = R/s Avg: .. Min: .. Max: .. Err: .. (E%)) и транслирует её в k6-совместимый блок сводки, в котором отчитывается каждый движок:

http_req_duration......: avg=4.00ms min=3.00ms max=72.00ms
http_req_failed........: 0.00%
http_reqs..............: 100 109.2/s

Без перцентилей. Консольная сводка их не содержит, поэтому у http_req_duration есть только avg/min/max. Если нужны p95/p99, используйте собственные средства отчётности JMeter (HTML-отчёт или Backend Listener) параллельно с прогоном — см. Ограничения.

Параметризация планов

Поскольку -J-свойства извне не передаются, параметризуйте сам план с помощью property-функций JMeter и значений по умолчанию:

<stringProp name="ThreadGroup.num_threads">${__P(vus,5)}</stringProp>
<stringProp name="LoopController.loops">${__P(loops,20)}</stringProp>
<stringProp name="HTTPSampler.domain">${__P(host,127.0.0.1)}</stringProp>
<stringProp name="HTTPSampler.port">${__P(port,8080)}</stringProp>

Значения по умолчанию позволяют запускать план как есть; чтобы менять форму нагрузки, оберните вызов jmeter в скрипт, передающий -Jvus=50 -Jloops=100, или держите несколько тонких вариантов плана под разные профили.

Запуск на агенте (PerfScale Cloud)

Платформу обслуживает тот же раннер: тест типа JMeter хранит XML плана, control plane отправляет его на агент, и агент выполняет его через POST /api/v1/run/jmeter — стримя лог в реальном времени и помещая транслированную сводку в тот же дашборд и тот же конвейер метрик, что и прогоны k6.

Ограничения

  • Без перцентилей в сводке (только avg/min/max) — консольная сводка JMeter их не содержит.
  • Нет гейтов std/thresholds@v1 для прогонов JMeter — гейтом в CI служит код выхода.
  • Файлы результатов .jtl не разбираются (парсинг пропускной способности из .jtl — план на будущее).
  • Без внешней параметризации — конфигурация perfscale и -J-свойства не применяются; формой нагрузки управляет план.

Сводное сравнение компромиссов по движкам см. в справочнике раннеров.