Apache JMeter review

What JMeter is

Apache JMeter is the load testing tool most of us started with, and there is a reason it is still the first name that comes up in any tool discussion. It is a Java desktop application where you build a test plan as a tree: thread groups, samplers, controllers, listeners, and assertions. The plan is saved as a JMX file, which is XML, and the same file runs from the GUI, from the command line, from Maven, from Docker, and from every commercial cloud runner in the market.

That portability is the real asset. When a customer asks me which tool their whole organization can standardize on, JMeter is usually the honest answer, because the tester who prefers a GUI, the developer who prefers Groovy, and the platform team that wants to run it in Kubernetes all get what they need from one plan.

In practice

Authoring a first HTTP plan takes an afternoon. Recording via the HTTP(S) Test Script Recorder works, but I always tell my students to hand-build the important requests and use the recorder only to discover them. Correlation is where the real effort goes: extracting tokens with the JSON or Regular Expression extractors and feeding them into the next sampler. It is verbose compared with k6 or Gatling, but it is also fully visual, which is exactly what non-programmers need.

For load runs, never use the GUI. Run jmeter -n with a JTL results file and generate the HTML dashboard afterwards. On a 4 core load generator I comfortably drive a few hundred threads with realistic think time; beyond that the thread-per-user model starts eating heap, and you add more injectors or move to a cloud runner. Distributed mode still works over RMI, but I find Taurus or a commercial runner less painful for anything beyond two or three machines.

Where it falls short

The XML plan is hostile to code review. Two engineers changing the same JMX will fight through diffs that no reviewer can read. Memory per thread is high, so JMeter needs more hardware than Go or JVM async tools for the same concurrency. The stock HTML dashboard is fine for a quick look but most teams end up shipping results to InfluxDB and Grafana through the Backend Listener, and that is one more thing to operate. And the GUI, honestly, looks the same as it did a decade ago.

AI features

JMeter itself has no AI. That gap is what pushed me to build Feather Wand, the JMeter AI agent, and JMeter.AI: they sit next to the GUI and help generate elements, explain plans, and analyse results. Treat these as assistants for authoring and analysis; the load engine itself is unchanged and deterministic, which is what you want.

Bottom line: if you need protocols beyond HTTP, a GUI for the team, and zero licensing cost, JMeter is still the safest default in 2026. Keep the GUI for authoring, run headless everywhere else, and pair it with Taurus or a Grafana backend for reporting. If your tests must be code in a pull request, look at k6 or Gatling instead.