Next Practical Step
From the plan directory, run jmeter -n once with -j jmeter.log and fix the first path or property error in that log.
Fix JMeter plans that pass in GUI but fail in non-GUI CLI: working directory, CSV paths, -J properties, plugins, headless network, and result paths.
Green samples in the GUI with a few threads
Same .jmx fails under:
jmeter -n -t plan.jmx -l results.jtlFailures often show missing files, wrong host, plugin/class errors, or connection errors only on the CI agent
Official stance: use GUI to build and debug; use non-GUI for real load (best practices). CLI is required in CI/CD and containers.
| Cause | Detail |
|---|---|
| Working directory | Relative CSV, keystore, or payload paths resolve from different cwd |
| Properties | GUI used defaults or GUI-set props; CLI missing -J / -q |
| Plugins missing | CI image or server install lacks lib/ext JARs (plugins) |
| Headless network | Agent cannot reach SUT (ConnectException) |
Different user.properties | Local custom props not present on the agent |
| Output paths | -o report dir already exists / not writable |
| Java version skew | Different JVM behaviour or TLS defaults |
Run CLI on the same machine as the successful GUI run first:
cd /path/to/plan-dirjmeter -n -t plan.jmx -l results.jtl -j jmeter.log -e -o report/Open jmeter.log for file-not-found, class-not-found, or SSL lines.
Make CSV and resource paths stable (relative to plan location or absolute). CSV Data Set is the documented multi-user pattern (best practices).
Parameterize hosts and threads with `\${__P(name,default)}` and pass the same -J flags you expect in CI (functions).
Mirror plugins into the CLI environment; restart after installs.
In Docker/K8s, mount plans and outputs explicitly (Docker guide); use qainsights/jmeter or your pinned image consistently.
Only after local CLI is green, run the same command in CI with the same properties and network access.
| Resource | Use when |
|---|---|
| CI/CD load testing | Pipeline patterns |
| Plugins essentials | Missing elements in CLI |
| ConnectException | Network only in CI |
| Properties cheat sheet | Env differences |
No. Always prove non-GUI once. Production and CI never use the GUI for load.
GUI often starts with a cwd near the plan or last open file. CLI cwd is wherever you launched the process. Prefer plan-relative layout and document the launch directory.
Same engine, different resource profile (no GUI listeners). Functional failures are usually path/property/plugin/network differences, not -n itself.