Apache JMeter: Load Testing Plans, Samplers & Reports

Q: How do I generate an HTML report?

Run with -l results.jtl -e -o report-folder in non-GUI mode, or generate a report later from an existing results file with jmeter -g results.jtl -o report-folder.

Apache JMeter

Apache JMeter is one of the oldest and most widely used open-source load testing tools. It simulates many users sending requests to a system — web applications, REST and SOAP APIs, databases over JDBC, message brokers, FTP, LDAP — and measures response times, throughput, and errors as load increases. Tests are built in a desktop GUI and saved as XML test plans (.jmx files), then run headless from the command line or in CI.

JMeter's strengths are protocol breadth, a large plugin ecosystem, and familiarity across QA teams. Its weaknesses are a heavyweight GUI-centric workflow and XML test plans that are awkward to review — which is why code-first tools such as k6, Gatling, and Locust have become popular for teams that want load tests in version control alongside application code.

TL;DR

A test plan contains thread groups (virtual users), samplers (requests), and supporting elements.
Use config elements for shared settings, extractors to correlate dynamic values, and assertions to detect wrong responses.
Control load deliberately: thread groups model concurrent users; throughput timers model arrival rates.
Build in the GUI, but run in non-GUI mode: jmeter -n -t plan.jmx -l results.jtl -e -o report/.
Parameterize plans with properties so CI can change users, duration, and target host.
Disable heavy listeners during load runs; analyze results afterwards.

Quick Example

Run an existing plan headless against staging, with load settings passed as properties, and generate the HTML dashboard:

Inside the plan, the thread group and HTTP sampler read those properties instead of hard-coded values:

The same .jmx file then serves a quick smoke test on a laptop and a 15-minute, 200-user run in CI. The generated dashboard shows response-time percentiles, throughput, and errors over time.

Core Concepts

Test Plan Elements

Correlation

Real flows pass dynamic values between requests: session tokens, CSRF tokens, created IDs. Extractors capture them from one response into variables used by later requests. Without correlation, scripts replay stale values recorded during script creation, and every request after login fails — often with a 200 error page that looks like success unless assertions check the content.

Workload Models

Public-facing services receive open workloads — new visitors keep arriving even when the site is slow — so closed models can hide how badly a slow system degrades. See Performance Testing.

Running Load Tests Well

Non-GUI mode only for real load; the GUI consumes memory and distorts results.
Write raw results to a .jtl file and build reports afterwards, instead of keeping graph listeners in the plan.
Size the load generator: watch its CPU, memory, and network — a saturated generator reports the generator's limits, not the system's.
Distributed testing uses several JMeter servers driven by one controller when one machine cannot produce enough load; cloud services can run plans at scale.
Warm up before measuring and run long enough to see garbage collection, caches, and autoscaling settle.

JMeter Compared With Code-First Tools

If your team already has a library of JMeter plans and protocol needs beyond HTTP, JMeter remains a solid choice. For new HTTP-focused tests owned by developers, code-first tools are usually easier to review and maintain.

Best Practices

Assert on Content, Not Just Status

Add assertions for expected text, JSON fields, and maximum durations. Error pages served with status 200 are the classic way load tests report false success.

Use Realistic, Varied Data

Feed users, products, and search terms from CSV files so caches and databases see realistic access patterns rather than the same request repeated.

Define Pass/Fail Criteria Up Front

Agree on targets — for example p95 under 400 ms and errors under 0.5% at 300 requests per second — and evaluate results against them, ideally automatically in CI.

Keep Plans Maintainable

Use modules and includes for shared flows, name every element clearly, parameterize everything environment-specific, and keep plans in version control with reviewable changes.

Common Mistakes

Load Testing From the GUI

Missing Correlation

Measuring the Load Generator

FAQ

What is Apache JMeter used for?

Load, stress, and performance testing of web applications, APIs, databases, and other services by simulating many concurrent users and measuring response times, throughput, and errors.

Should I run JMeter in GUI mode?

Only to build and debug test plans with a few users. Real load tests should run in non-GUI mode, which uses far fewer resources and produces more reliable measurements.

How do I generate an HTML report?

Run with -l results.jtl -e -o report-folder in non-GUI mode, or generate a report later from an existing results file with jmeter -g results.jtl -o report-folder.

What is the difference between threads and throughput?

Threads are concurrent virtual users. Throughput is requests per second. With a standard thread group, throughput depends on response times and think time; to target a specific rate, use a throughput timer or an arrival-based thread group.

Is JMeter better than k6?

It depends on the team and protocols. JMeter offers broad protocol support and a GUI; k6 offers scripts in JavaScript that fit naturally into code review and CI. Both produce trustworthy results when the workload is designed carefully.