Apache JMeter review: what it is, tutorial and alternatives

Everything in JMeter is an element in a tree: thread groups, samplers that send requests, config elements such as HTTP Request Defaults and the Cookie Manager, timers, pre- and post-processors, assertions and listeners. Where an element sits decides what it applies to. A timer placed under a thread group runs before every sampler in that scope; placed under one sampler, it runs only before that one. The same rule governs extractors and assertions. Most confusing behaviour in a plan, such as a delay that applies twice or an extractor that overwrites a variable, comes from scope. The GUI saves the tree as a .jmx XML file, which is what the command line runs.

A Thread Group starts a fixed number of threads, each one a virtual user that runs the plan in a loop. Ramp-up spreads thread start times over a period, with the first thread starting at once, and the group ends after a loop count or a duration. This is a closed model: a thread sends its next request only after the previous one returns, so when the server slows down, the request rate falls with it. JMeter 5.5 added an experimental Open Model Thread Group that schedules arrivals by rate instead, for example rate(10/sec) random_arrivals(5 min), which keeps pressure constant whatever the response time.

JMeter sends requests and reads responses; it does not render pages or execute the JavaScript in them, as its own documentation states. An HTTP sampler can fetch embedded resources such as images and stylesheets, and the Cookie Manager and Cache Manager imitate a browser’s session and cache, but a single-page application’s client-side work is invisible. That is why JMeter scales further per machine than browser-based load and why correlation matters: any value the browser would have computed or read from a response, the plan must extract and send back itself.

Every sampler produces a sample result with timings, size, status and success. Listeners consume them: View Results Tree shows each request for debugging, while a run started with -l writes them to a JTL file, CSV by default. In command line mode the summariser prints running totals to the console, and the HTML dashboard is generated from the JTL either at the end of the run with -e -o or later with -g. Because results are plain CSV, the same file can be re-analysed, merged or fed into another tool.

For more load than one machine can produce, a controller sends the plan over Java RMI to jmeter-server processes on other machines and collects their samples. Each server runs the whole plan, so 1,000 threads on six servers means 6,000 threads. Data files are not sent, so every server needs its own copies. Since JMeter 4.0, RMI uses SSL by default, which means a keystore must be generated and copied to every node before the first distributed run, or SSL explicitly disabled. All nodes should run exactly the same JMeter version.

Keep one plan per scenario, such as browse, checkout or search, in a perf folder of the application repository, with CSV data files beside them and referenced by relative path. Put the host, protocol and port in HTTP Request Defaults, and read thread counts, ramp-up, duration and host from properties with __P, so the same plan runs against staging with -J overrides and nobody edits XML to change the load. Shared steps such as login belong in a Test Fragment called through a Module Controller or Include Controller. Wrap each user action in a Transaction Controller so the report shows business steps rather than individual requests. Because JMX diffs are hard to read, describe the intent of each change in the pull request, give each plan one owner, and keep the whole team and every load generator on the same JMeter version.

Record the journey, then find every value the server issues that a later request sends back: session IDs, CSRF tokens, order numbers. For each, add an extractor under the response that issues it and replace the hard-coded value with a variable, for example an Authorization header of Bearer ${authToken} in a Header Manager. A JSON Extractor handles most APIs. When the value needs logic, use a JSR223 PostProcessor in Groovy, not BeanShell: the project recommends JSR223 with Groovy for performance, because Groovy scripts are compiled and cached. Feed credentials from a CSV Data Set Config so each thread logs in as a different user, and give the file enough rows for the thread count.

There is no official JMeter action, and you do not need one: install Java with actions/setup-java, download a pinned JMeter release, verify its checksum and run in CLI mode. JMeter has no built-in pass or fail criteria, so a completed run is not a passing run. The dashboard step writes statistics.json, and a jq check on the Total entry fails the job when the error percentage or a percentile crosses your threshold. Upload the report and jmeter.log as artifacts whatever the result. Keep CI runs short and modest, a few minutes at a fraction of peak, to catch regressions on every change, and run full-scale tests from dedicated load generators where the CI runner cannot become the bottleneck.

When one generator runs out of CPU or memory, add servers rather than threads. Install the same JMeter and Java versions on every node, generate an RMI keystore once with the bundled script, and copy rmi_keystore.jks into the bin folder of every server and the controller. The generated key is valid for seven days, so automate its creation or a weekly run will fail. Fix the server’s RMI port with server.rmi.localport so firewall rules can be written, copy CSV files to each server, and remember that thread counts multiply by the number of servers. Start the run from a CLI controller and pass properties to the servers with -G, since -J only sets them locally.

Read percentiles, not averages: the dashboard’s statistics table shows the 90th, 95th and 99th by default, and the response time over time graphs show whether the system degraded during the run or was slow from the start. Set APDEX thresholds in user.properties to match your own targets rather than the 500 and 1,500 millisecond defaults. For long soak tests, stream results through the Backend Listener to InfluxDB and Grafana so you can watch the run live. Keep plugins under control with the Plugins Manager’s command line, whose install-for-jmx command installs exactly what a plan needs on each machine. Re-record or re-check correlation after every significant release of the application, because a stale token extractor usually shows as a wave of 401 or 403 errors rather than slower responses.