How to Size Load Generators in CI
If the load generator is CPU-bound, your latency numbers measure the runner, not the service, so size the generator to have headroom.
Watch the generator's CPU during a run. A standard runner handles a few thousand virtual users for HTTP; beyond that, move to a larger runner or split the load across pods with the k6 Operator.
Steps
- Run a baseline and watch generator CPU (
k6prints dropped iterations when saturated). - If CPU pegs at 100 percent, the results are unreliable.
- Scale up the runner or scale out across pods.
Choosing a scale strategy
| Symptom | Action |
|---|---|
| Generator CPU under 70 percent | One standard runner is fine |
| Dropped iterations, CPU pegged | Use a larger runner |
| Larger runner still saturates | Distribute with the k6 Operator |
Gotchas
- k6 warns "Insufficient VUs" or drops iterations when the generator cannot keep up.
- Network egress limits on the runner can cap throughput before CPU does.
Related guides
How to Run Distributed Load Tests With the k6 OperatorRun distributed k6 load across multiple runners with the k6 Operator on Kubernetes, splitting virtual users o…
When Not to Run Heavy Load Tests in CIKnow when heavy load tests do not belong in per-PR CI because of cost, runner limits, and shared-environment…