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
- Made by
- Apache Software Foundation
- 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
.jmxfiles 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 machineSee 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
- 1999
Versions 1.0.1 to 1.4 are released between January and July
- 2011
JMeter becomes a top-level Apache project in November
- 2024
JMeter 5.6.3, the latest release, in January
- 2026
The main branch prepares 6.0, requiring Java 17
Sources10 · facts checked 23 October 2026
- Apache JMeter: home page (protocols, features, no JavaScript execution)
- JMeter user manual: Building a test plan (thread groups, threads run the plan independently)
- JMeter user manual: Getting started (Java 8+, CLI mode, 1 GB default heap)
- JMeter user manual: Best practices (CLI mode, few listeners)
- JMeter user manual: Remote testing (-R, same plan on every server, RMI)
- JMeter: Distributed testing step by step (same subnet, versions, 1,000–2,000 threads per machine)
- JMeter user manual: Real-time results (Backend Listener, InfluxDB, Grafana)
- JMeter download page (5.6.3, requires Java 8+)
- JMeter source: changes.xml for 6.0.0 (requires Java 17)
- GitHub: apache/jmeter (Apache 2.0)