Observation
Same k6 script produced different results on two machines: 8 GB laptop vs. 32 GB laptop. The discrepancy pointed to the load generator itself being the bottleneck, not the system under test.
Why this happens
Each k6 VU is a single-threaded JavaScript runtime with its own event loop. When the host runs out of CPU or memory, the event loops can’t process callbacks efficiently — this shows up as artificial latency in results, making the target system look slower than it is.
k6 can handle 30,000–40,000 VUs on a well-resourced machine, but on a constrained host even a few hundred VUs can saturate it.
Warning
Skewed results from a saturated load generator are silent — the test completes and reports numbers, but those numbers reflect the generator’s limits, not the target system’s behaviour.
Signals
- Results differ significantly between machines with different RAM/CPU
- CPU utilisation on the test machine hits ~100% during the test
- Latency percentiles plateau in a way that mirrors CPU saturation, not server behaviour
http_req_tls_handshakingavg is high — TLS handshakes are CPU-intensive; saturation delays them
Guidelines
| Metric | Safe threshold |
|---|---|
| Load generator CPU | < 80% |
| Load generator memory | < 90% |
- Scale gradually — ramp up VU count while watching generator metrics before reading target metrics
- Prefer arrival-rate executors (
constant-arrival-rate,ramping-arrival-rate) over VU-based executors — they give more predictable resource usage - Pre-allocate VUs with
preAllocatedVUsrather than relying onmaxVUsto scale mid-test, which causes sudden resource spikes - Run tests on a consistent spec — don’t compare results across machines with different RAM unless you’ve verified the generator was not the bottleneck on both
See also
- k6-connection-limits — hitting TCP connection limits at high VU counts even with OS tuning done
- k6-large-tests — OS tuning, hardware thresholds, script optimisations, and distributed execution
- k6-script-config — connection reuse settings and tagged sub-metrics
- k6-http-metrics — metric interpretation and validation workflow