Response Time vs. Virtual Users
Response time vs. virtual users
Below the timeline chart, the Timeline tab plots average and maximum response time against the number of virtual users that were active, one point per level of the ramp. When the run had errors, the error rate at each level is drawn on the right axis.
How it is built
For every second of the run LoadFocus adds up the active threads on every load-generator location, then groups the samples by that total. A run that ramped from 1 to 50 users therefore shows one point per user count actually reached, not one per second.
Reading the knee
- A flat line - response time does not depend on load in the range tested. The application had headroom; raise the number of users next time.
- A gentle slope - the application is queueing but coping. Note the user count where P95 crosses your budget.
- A bend (the knee) - the level after which response time climbs steeply or errors appear. This is the practical capacity for this configuration. The capacity panel on the Overview estimates the same number from the run.
- Errors rising before response time does - a hard limit such as a connection pool, rate limiter or worker count, rather than slow code.
What to check next
Compare the slowest requests at the knee with those at low load, and make sure the load generators were not saturated - a saturated generator bends the line too, for the wrong reason.