Apache JMeter

Apache JMeter is the oldest tool still in active use in the load-testing category — an Apache Software Foundation project that started in 1998, years before "cloud-native" was a phrase anyone used, and it has been in continuous production use ever since. It's a pure-Java desktop application built around a GUI test-plan designer that serializes everything you build into an XML file, and its protocol support runs far past plain HTTP into databases, message queues, and file transfer — territory most of its younger, code-first competitors don't cover at all. This page walks through that GUI-and-XML model, the protocols JMeter actually speaks, the commands you run for a real test, and the operational fact every team eventually rediscovers the hard way: at high enough concurrency, JMeter's own CPU and memory become the thing you're measuring, not your service.

What JMeter is and where it came from

☺ Like you're 10: It's been the standard way to test load since 1998 — built to test one specific Apache project, then it outgrew that and became everyone's tool.

Stefano Mazzocchi wrote the first version of JMeter in 1998 to load-test Apache JServ, the servlet engine that would later evolve into Apache Tomcat. It became an Apache Jakarta project and, eventually, a top-level Apache Software Foundation project in its own right — which makes it roughly two decades older than k6, Locust, or Gatling, all of which arrived well into the 2010s. That age shows up in two ways, one good and one worth knowing about going in. The good: an enormous body of institutional knowledge, Stack Overflow answers, enterprise support contracts, and a plugin ecosystem — the community-maintained JMeter Plugins Manager adds samplers, listeners, and timers the core project never shipped, including WebSocket, MQTT, and Kafka support. The catch: JMeter is a Java desktop application at heart, with a Swing GUI as its primary authoring surface, and that architectural choice — a real GUI, a real JVM, real OS threads per virtual user — is the throughline for almost everything distinctive about it, good and bad, covered on this page.

JMeter is not a niche tool. It's on the SRE toolchain's load/performance testing row alongside k6, Locust, and Gatling precisely because a huge number of organizations — especially ones with an existing Java estate, a QA team more comfortable with a GUI than a scripting language, or systems that need JDBC or JMS coverage no JavaScript-based tool touches — still reach for it first.

The GUI-and-XML test-plan model

☺ Like you're 10: You build the test by clicking and dragging boxes into a tree, and every click gets written down as XML behind the scenes — you're not typing code, you're assembling a diagram.

Where k6, Locust, and Gatling all start from a text editor and a scripting language, JMeter starts from a tree. Every JMeter test is a Test Plan: a hierarchy of elements you assemble in the desktop GUI by right-clicking and adding nodes, and the whole tree is saved as a .jmx file — JMeter's own XML dialect. The element types that make up that tree cover almost everything a test needs:

• Thread Groups — the unit of concurrency. Each thread in a Thread Group is a real, independent virtual user that runs the group's children in a loop, for a fixed number of loops or a fixed duration, ramping up to full thread count over a configurable ramp-up period.
• Samplers — the actual requests: HTTP Request, JDBC Request, JMS samplers, FTP Request, and more, covered in full below.
• Config Elements — shared setup a sampler pulls from: HTTP Request Defaults, HTTP Cookie Manager, HTTP Cache Manager, CSV Data Set Config for parameterized input, JDBC Connection Configuration for a pooled database connection.
• Pre/Post-Processors and Assertions — a Regular Expression Extractor or JSON Extractor pulls a value out of one response to feed the next request (the mechanism that makes multi-step, session-aware flows possible); a Response Assertion fails the sample if the body or status code doesn't match what's expected.
• Timers — Constant Timer, Uniform Random Timer, and friends insert think-time between requests so a test doesn't fire every request back-to-back with zero pacing.
• Listeners — where results go: View Results Tree, Summary Report, Aggregate Report, or a Backend Listener streaming to InfluxDB or a similar time-series store.

Here's roughly what a small slice of that tree looks like once it's saved to disk. Treat the exact element attributes as illustrative — the .jmx schema shifts in minor ways release to release, and the GUI is the authoritative way to generate one; hand-authoring this XML from scratch is technically possible and practically miserable.

<?xml version="1.0" encoding="UTF-8"?>
<jmeterTestPlan version="1.2" properties="5.0" jmeter="5.6.3">
  <hashTree>
    <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Checkout capacity test" enabled="true">
      <boolProp name="TestPlan.functional_mode">false</boolProp>
      <boolProp name="TestPlan.tearDown_on_shutdown">true</boolProp>
    </TestPlan>
    <hashTree>
      <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Checkout users" enabled="true">
        <stringProp name="ThreadGroup.num_threads">200</stringProp>
        <stringProp name="ThreadGroup.ramp_time">60</stringProp>
        <elementProp name="ThreadGroup.main_controller" elementType="LoopController">
          <stringProp name="LoopController.loops">10</stringProp>
        </elementProp>
      </ThreadGroup>
      <hashTree>
        <HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="POST /checkout" enabled="true">
          <stringProp name="HTTPSampler.domain">checkout.internal</stringProp>
          <stringProp name="HTTPSampler.path">/api/checkout</stringProp>
          <stringProp name="HTTPSampler.method">POST</stringProp>
        </HTTPSamplerProxy>
        <hashTree/>
      </hashTree>
    </hashTree>
  </hashTree>
</jmeterTestPlan>

Protocol breadth well beyond HTTP

☺ Like you're 10: Most load testers only speak "web page." JMeter also speaks "database," "message queue," and "file transfer" — a much bigger vocabulary.

This is JMeter's clearest differentiator against every newer tool in the category. k6, Locust, and Gatling are all built HTTP-first (with gRPC and WebSocket support layered on more recently); JMeter shipped native, non-HTTP samplers from early in its life, because it grew up inside enterprise Java shops where "the system under test" routinely meant a database or a message broker, not a web endpoint.

Community plugins extend this further — WebSocket, MQTT, and Kafka samplers all exist in the JMeter Plugins Manager, though they're maintained outside the core project and worth checking for update cadence before depending on one in a critical test suite.

# A JDBC Connection Configuration config element, in the values you'd actually set in the GUI:
Variable Name bound to pool:  checkoutDbPool
Database URL:                 jdbc:postgresql://db-replica.internal:5432/checkout
JDBC Driver class:             org.postgresql.Driver
Max Number of Connections:     50     # this pool is PER THREAD GROUP THREAD by default — read that twice
Max Wait (ms):                 5000
# A JDBC Request sampler then references it by the same Variable Name and runs, e.g.:
#   SELECT status FROM orders WHERE order_id = ?
# with ? parameters bound from a CSV Data Set Config for realistic, varied input.

Architecture: where the load actually comes from

☺ Like you're 10: One computer running JMeter can only pretend to be so many people at once — for a really big test, you need several computers pretending together, and something has to add up all their notes afterward.

Every JMeter thread in a Thread Group is a genuine OS-level thread inside one JVM process, each holding its own connection state, response buffers, and variable scope. That's heavier than the lightweight coroutine or event-loop models k6, Locust, and Gatling use internally — the direct cause of the resource ceiling covered under gotchas below — and it's also why JMeter has supported distributed testing since early versions: when one machine's threads aren't enough, you add machines, not more threads on the same box.

Every worker in that diagram needs an identical .jmx and matching JMeter version and JDK — a mismatch is a common source of a distributed run that silently behaves differently on one node than the others. The controller's job is purely to fan the test out and aggregate results back; it does not generate load itself in a distributed run, and treating it as just another worker under-counts real capacity.

The commands you actually run

☺ Like you're 10: Build and check your test with the picture-clicking window, but the real test always runs with the window closed.

The GUI is for building and debugging a test plan with a handful of threads — it is never the way you generate real load, for reasons covered under gotchas next. The engine you actually run load through is non-GUI mode.

# the standard way to run a real test: non-GUI, write raw samples to a .jtl,
# then generate the HTML Dashboard Report from that .jtl when it's done
$ jmeter -n -t checkout-capacity.jmx -l results.jtl -e -o report/

# give the JVM real headroom before you scale threads up — the default heap is small
$ JVM_ARGS="-Xms1g -Xmx4g" jmeter -n -t checkout-capacity.jmx -l results.jtl

# override a test-plan property from the command line without editing the .jmx
$ jmeter -n -t checkout-capacity.jmx -Jusers=500 -Jrampup=120 -l results.jtl

# DISTRIBUTED: start the engine on each worker first (defaults to RMI port 1099)
worker$ jmeter-server

# then drive them all from the controller — same .jmx, same JMeter version on every node
controller$ jmeter -n -t checkout-capacity.jmx -R worker-1,worker-2 -l results.jtl -e -o report/

# regenerate just the HTML dashboard from an existing .jtl, without re-running anything
$ jmeter -g results.jtl -o report/

# sanity-check a test plan's structure before you run it at all
$ jmeter -n -t checkout-capacity.jmx --report-output-folder /tmp -l /dev/null -e -o /tmp/report -n

Watching the generator's own health during a run is not optional at real scale. The community PerfMon Server Agent plugin runs a lightweight agent on each load-generating machine and feeds its CPU, memory, and network numbers into a PerfMon listener back on the controller — the direct way to answer "is it them or is it us" without guessing, the exact question the schematic above and the gotcha below both turn on.

Gotchas and failure modes

☺ Like you're 10: Most JMeter surprises come from treating it like a lightweight tool when it's actually a fairly heavy one — the fixes are almost all "run it a leaner way," not "the tool is broken."

• Running real load from the GUI. The Swing GUI itself consumes CPU and memory rendering every result as it streams in, competing directly with the threads it's supposed to be driving. Beyond a few dozen threads the GUI's own overhead measurably distorts the numbers. Build and debug in the GUI with a handful of threads; always execute the real test in non-GUI mode.
• Heavy listeners left enabled at scale. View Results Tree and View Results in Table keep every request and response body in memory for inspection — fine for debugging five samples, a memory leak waiting to happen at five thousand. Disable them for a real run and rely on -l results.jtl plus a Summary Report or Aggregate Report, or a Backend Listener streaming to InfluxDB for large or long-running tests.
• Non-GUI mode that never exits. Certain protocol libraries spawn non-daemon threads that keep the JVM alive after a test technically finishes, leaving a run that looks hung. -Jjmeterengine.force.system.exit=true forces a hard exit once the test plan completes, and is worth setting by default in CI.
• Aggregate/Summary Report percentiles are an approximation, not a computed statistic. Both listeners calculate percentiles from a rolling in-memory sample rather than the full result set once a run gets large, which is adequate for a live sanity check but not for a number you'll cite in a capacity plan. For anything that matters, generate the HTML Dashboard Report from the full .jtl (jmeter -g results.jtl -o report/) or post-process the raw file yourself.
• Missing correlation breaks multi-step flows silently. A CSRF token, session ID, or order ID returned by one response and required by the next has to be captured with a Regular Expression Extractor or JSON Extractor and substituted back in — skip it and every subsequent request in the chain either 400s or, worse, quietly hits a cached or generic error page that still returns 200, making the test look healthy while testing nothing real.
• No Cookie Manager or Cache Manager means every request looks like a fresh browser. Without an HTTP Cookie Manager and HTTP Cache Manager attached, JMeter won't carry session cookies between requests or respect cache headers the way a real client does — a test that's unintentionally more pessimistic (no session reuse) or unrealistic (no cache hits) than production traffic.
• The default Thread Group models a fixed population, not a fixed arrival rate. A standard Thread Group holds concurrency (a set number of threads looping) constant and lets throughput vary with response time — a closed model. Real production traffic is usually closer to an open model, where new requests arrive at some rate λ regardless of how fast the last one finished — the same arrival-rate concept queueing theory for SRE builds Little's Law around. If a fixed request rate matters more than a fixed user count, reach for a Constant Throughput Timer or a plugin-provided Concurrency Thread Group instead of assuming the default behaves like real traffic.

Alternatives and when to reach for something else

☺ Like you're 10: The newer tools trade away some of JMeter's protocol breadth and GUI-friendliness for being lighter on their feet — which one wins depends on what you're testing and who's writing the test.

The practical rule most teams land on: reach for JMeter when the system under test isn't purely an HTTP API — a database connection pool, a message broker, an FTP endpoint — or when non-programmers need to build and maintain tests through a GUI; reach for k6, Locust, or Gatling when the target is HTTP/gRPC-shaped, the team writing tests is comfortable in code, and squeezing the most virtual users out of the fewest generator nodes matters more than protocol breadth. Plenty of mature testing practices keep both: JMeter for the JDBC and JMS suites nothing else covers, a lighter tool for everyday HTTP regression load tests in CI. See the SRE toolchain for how the whole load-testing category sits next to monitoring and paging tools, and queueing theory for SRE for the arrival-rate math a good load test should actually be validating.

Going further

☺ Like you're 10: This page covers the tool; the next pages cover what the numbers it gives you are actually for.

The canonical source is the Apache JMeter user manual at jmeter.apache.org — confirm exact element names, current sampler lists, and version-specific behavior there, since JMeter's own release notes are the authority on anything this page simplified for space. Pair this page with capacity planning & performance for what a load test's results are actually for, queueing theory for SRE for the arrival-rate math behind a realistic test design, and the SRE toolchain for how JMeter sits next to k6, Locust, and Gatling in the broader tool landscape. For hands-on practice, work through Drill — Forecast the Bottleneck and Capstone Part 5 — Capacity Plan & Load Test.