JMeter Load Testing Template
A reusable Apache JMeter load-testing template: 500 concurrent virtual users, an HTML dashboard with real-time latency and failure-rate charts, and a threshold-check script. Fork it and point it at your own service.
Overview
A starter template for load and stress testing with Apache JMeter: a test plan that ramps up to 500 concurrent virtual users, an HTML dashboard with real latency and failure-rate charts, and a threshold-check script that turns those numbers into a pass/fail gate. It ships with its own target: a small, zero-dependency Node microservice with a deliberately limited-capacity endpoint, so the test plan has a real breaking point to find instead of hitting an always-healthy stub.
Why a Local Target, Not a Public Site
500 concurrent virtual users is real sustained load. Pointing that at a public site or API you don't own is a denial-of-service risk and almost certainly violates its terms of service. This template's target service exists specifically so the full-scale benchmark has somewhere safe to run: your own machine, testing your own process.
What the Example Demonstrates
The mock service is deliberately simple: a fast, unbottlenecked read endpoint, and a write endpoint that simulates a backend with limited capacity, at most 25 requests processed concurrently, up to 50 more queued, and anything beyond that rejected immediately with a 503. That's a stand-in for a real constraint like a database connection pool.
Running the full plan at 500 virtual users against it found exactly the failure mode it was built to find:
| Endpoint | Requests | Error Rate | p95 Latency |
|---|---|---|---|
| Unbottlenecked | 28,357 | 0.00% | 29ms |
| Bottlenecked | 28,130 | 34.28% | 343ms |
| Combined | 56,487 | 17.07% | 338ms |
The interesting part isn't just that the bottlenecked endpoint failed under load, it's how it failed. Latency remained bounded because the service fails fast once its queue is full, rather than letting requests pile up. That's a real design tradeoff: a backend that sheds load aggressively protects its latency numbers at the direct cost of its availability numbers. A load test that only looked at response time would have missed the problem entirely, it only shows up in the error rate. That's why the threshold check looks at both.
Using It
- Point the test plan at your own service via JMeter properties, no need to hand-edit the plan.
- Replace the request flow to match your own app's endpoints.
- Set thresholds that mean something for your app: error rate and p95 latency per endpoint, checked automatically after every run.
- Keep the shape: non-GUI mode for real load, a duration-based thread group, and a smoke-scale CI run that's separate from the real benchmark, since shared CI runners can't produce trustworthy performance numbers.
Why a Template
The tedious part of load testing isn't writing a JMeter plan, it's having something safe and realistic to point it at. This template solves that: a working target with a genuine capacity limit, a dashboard, and a threshold gate, all proven end-to-end before you touch it.