Load Generator Saturation
Load generator saturation
Load is produced by machines too. If a load-generator engine spends the run near 100% CPU, it cannot send requests at the configured rate, and the response times it records include time spent waiting for its own CPU. The numbers then describe the generator, not your application.
The Overview shows a warning banner when any engine peaked at or above 80% CPU during the run, naming the engine and its peak. The full CPU, memory, network and disk series are on the Engine Health tab.
How to recognise it in the results
- Response time climbs with the number of virtual users, but the target's own monitoring shows it idle.
- Throughput flattens although the error rate stays at zero.
- One location is slower than the others and it is the one whose engine was hot.
Treat every response time from a saturated run as a lower bound: the real figure is at most that good.
How to fix the test
- Spread the same number of users across more engines or locations, so each engine does less work.
- Remove expensive per-request work from the script: large regular-expression extractors, JSON parsing of big bodies, per-request logging.
- Lower the number of users per engine and raise the ramp-up instead of starting everyone at once.
- Re-run and confirm the banner is gone before trusting the response time vs. virtual users chart.