A login page that works perfectly for one user can fall over at 500. Functional testing never reveals that — you need to apply load on purpose and watch what breaks.
The Questions Load Testing Answers
- How many concurrent users can the system handle before responses slow down?
- Where's the bottleneck — app, database, or network?
- Does it degrade gracefully or fall off a cliff?
- Does it recover after the load drops?
Setting Up a Basic JMeter Test
The building blocks:
Thread Group → how many users, how fast they arrive
HTTP Request → the endpoint under test
HTTP Header Mgr → auth tokens, content-type
Listeners → where results are collected
A first run: 100 threads (users), ramping up over 30 seconds, each hitting the search endpoint 10 times.
Reading the Results
| Metric | What it tells you |
| Average response time | Typical experience |
| 90th/95th percentile | What slow users feel — more honest than average |
| Throughput | Requests/second the system sustains |
| Error % | Where it starts failing under stress |
The 95th percentile matters more than the average. An average of 200ms can hide that 1 in 20 users waits 4 seconds.
What My First Test Found
Response time was flat up to ~150 users, then climbed sharply. The bottleneck wasn't the app — it was an unindexed database query that the search hit. Under light load it was invisible. Under load it dominated everything.
Test the Realistic Path, Not Just One Endpoint
Hammering a single endpoint gives a misleading number. Real users log in, browse, search, and check out in sequence. A load test that mirrors that journey surfaces contention — shared connections, locks, caches — that single-endpoint tests never touch.