cloudparts

Apache JMeter

The long-standing open-source load tester: a Java app where you build test plans in a GUI, then run them headless with many threads as virtual users.

Apache · Top-level project
What it is
Automated testing (load tests)
Type
Open source
Foundation
The Apache Software Foundation, top-level project
License
Apache 2.0
Facts checked
23 October 2026

What it is

A JMeter test plan is a tree of elements saved as an XML .jmx file. A thread group says how many virtual users to start, how fast to ramp them up and how often to loop; each user is a Java thread that runs the whole plan on its own. Samplers send the requests: HTTP and HTTPS, SOAP and REST, JDBC queries, JMS, LDAP, FTP, mail, TCP and shell commands. Extractors pull values such as session tokens out of HTML, JSON or XML responses, timers add think time, and assertions mark responses as failed. JMeter works at the protocol level: it is not a browser and does not run the JavaScript in a page.

You build and debug a plan in the desktop GUI, often by recording a browser session through its proxy, and then run it in CLI mode, which writes every sample to a results file and can generate an HTML dashboard of response times, throughput and errors. The docs warn never to run real load from the GUI. For more load than one machine can make, a controller sends the plan over Java RMI to jmeter-server processes on other machines, which all run the same plan. A Backend Listener can stream live results to InfluxDB or Graphite for Grafana. JMeter is free under Apache 2.0. The latest release is 5.6.3 from January 2024, which needs Java 8 or later; the main branch is preparing 6.0, which will need Java 17.

Why teams pick it

  • Most plans need no code: record a session, add extractors and assertions in the GUI, and save
  • Covers more than HTTP: JDBC, JMS, LDAP, FTP, mail, TCP and plain Java requests from the same tool
  • Built-in distributed mode and a ready HTML report, with no paid service needed
  • A built-in Backend Listener streams live results to InfluxDB or Graphite, so you can watch a test in Grafana while it runs

Watch out for

  • One thread per virtual user, with a 1 GB heap by default: the docs estimate 1,000 to 2,000 threads per machine, so large tests need distributed mode or more memory
  • .jmx files are verbose XML written by the GUI, awkward to review in pull requests compared with k6, Gatling or Locust tests written as code
  • Distributed mode uses RMI, which expects the machines on one subnet with the same JMeter and Java versions and firewall ports opened
  • Slow releases: nothing since 5.6.3 in January 2024, though the code is still worked on for 6.0

How it fits with other technologies

Run a saved plan headless, then across several load machines · bash

# Build and debug checkout.jmx in the GUI first (just run `jmeter`), then:
jmeter -n -t checkout.jmx -l results.jtl -e -o report/
#  -n  CLI mode (no GUI)        -t  the test plan
#  -l  raw sample results       -e -o  HTML dashboard into an empty folder

# More heap than the default 1 GB for big thread counts
HEAP="-Xms4g -Xmx4g" jmeter -n -t checkout.jmx -l results.jtl

# Distributed: start `jmeter-server` on each load machine, then
jmeter -n -t checkout.jmx -R 10.0.0.11,10.0.0.12 -l results.jtl
# each remote server runs the same plan; results come back to this machine

See it in a real stack

No architecture uses Apache JMeter yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from1999–2026

Stefano Mazzocchi, at the Apache Software Foundation, wrote the first version of JMeter to measure the performance of Apache JServ, the Java servlet engine that Apache Tomcat later replaced. Its changelog starts with version 1.0.1 in January 1999; by July of that year 1.4 had added cookies, HTTP authentication and new result visualizers.

The project later redesigned the GUI and added functional-testing features, then grew samplers for databases, messaging and directories. It became a top-level Apache project in November 2011, with its own project management committee. 5.6.3 came out in January 2024; since then the main branch has been preparing 6.0, which needs Java 17, stops sending expired cookies and drops the MongoDB sampler.

Why it’s built this way

Pure Java, with a desktop GUI
It ran anywhere Java did, and testers could build plans by pointing and clicking instead of writing code.
Work at the protocol level, not in a browser
It was written to measure a server, Apache JServ, so it sends the requests itself; it never renders pages or runs their JavaScript, which means it measures the server, not what a browser does.
One thread per virtual user
Each thread runs the plan from top to bottom, independently, with its own variables, so a plan reads like one user’s session; the price is memory per user, and the project lists a thread-pool or async core as a future goal.

Timeline

  1. 1999

    Versions 1.0.1 to 1.4 are released between January and July

  2. 2011

    JMeter becomes a top-level Apache project in November

  3. 2024

    JMeter 5.6.3, the latest release, in January

  4. 2026

    The main branch prepares 6.0, requiring Java 17

Sources10 · facts checked 23 October 2026

Improve this page on GitHub