API & load testing
JMeter
The long-standing Java load tool, plans built visually.
JMeter in practice
An Apache load testing tool with a long history, organised around a test plan assembled in a desktop interface from samplers, controllers, timers and listeners. Its reach is why it persists: HTTP is only the starting point, and plans routinely exercise databases over JDBC, message queues, mail protocols and directory services. Two decades of plugins, corporate familiarity and existing plans mean it is very often the load tool already installed in the building before anyone asks what should be used.
We use it where the protocol matters more than the authoring workflow. A performance question involving a database driver or a message broker is frequently answered faster here than in something designed for HTTP first, and a client sitting on a library of existing plans is better served by somebody who can read them than by a migration nobody requested. It also suits environments where the person who understands the load profile builds it visually rather than expressing it in a language they do not write.
The interface is for authoring, not for running. A real load run happens from the command line, and anyone generating load from the graphical mode is measuring the tool at least as much as the system under test.
Its threading model places a JVM thread behind each virtual user, so a single generator reaches its limit sooner than an event-driven one would, and heap settings become part of the test design rather than an operational afterthought.
Plans are XML. They sit in version control technically and unreviewably, so changes to load behaviour land without the scrutiny every other file in the repository receives as a matter of course.
The workflow resists pipelines and code review in general. Getting it into continuous integration is entirely possible and is always more work than with a tool that began life as a script.
As with every protocol-level generator, rendering is invisible to it. Anything about page-level experience needs a browser somewhere in the measurement, and that is a second tool.
FAQ
JMeter questions we hear often
Is JMeter still a reasonable choice?
For the right question, yes. Where the system involves protocols outside HTTP, or the team already holds plans and the people who understand them, it remains the shortest route to an answer worth having. For a fresh HTTP-only performance suite that needs to live in a pipeline, a code-first tool will sit more comfortably inside your existing engineering practices.
Why do our results vary between runs?
Suspect the generator before you suspect the system. Running from the graphical interface, leaving listeners enabled throughout, an injector short of heap, and shared state on the target all produce variance owing nothing to the application. Prove the load generator is not itself the bottleneck before anyone interprets a single number from the report.
Can we run it in our pipeline?
Yes, in non-graphical mode with results written out for a reporting step to collect afterwards. It is a well-trodden path carrying an unpleasant quantity of glue: file paths, heap flags, plugin availability on the agent, and a report that has to mean something to whoever opens it the following morning. Budget for the plumbing rather than the tool.
Should we migrate our existing plans?
Rarely, and never as a project standing on its own. A plan that still answers a question you still ask is working software. Migrate when the tests need to be in a pipeline and the glue has become the recurring cost, or when the people who understood those plans have left, because a plan nobody can safely modify is a liability in whatever tool it was written.
Contact
Wondering if this is the right tool?
Describe what you are trying to verify and we will tell you which instrument fits, including when the answer is one we do not use.