When is setting maxVUs above preAllocatedVUs in a k6 arrival-rate scenario worth its cost?

## What k6 actually does when it grows a pool `maxVUs` is not a reserve that sits ready. The difference `maxVUs - preAllocatedVUs` is a budget, and k6 spends it lazily, from inside the code path that has just dropped a scheduled start: 1. A start finds no idle VU and is dropped. 2. If budget remains, the executor sends a non-blocking signal to a background goroutine and decrements the budget. 3. That goroutine constructs a brand-new VU - a fresh JavaScript runtime with the script's init context executed again for it - and adds it to the pool. 4. k6 records this at debug level as *Initializing an unplanned VU, this may affect test results*. The costs are therefore paid at the worst possible moment: while the run is already under pressure, on the same machine that is generating the load. ## Why the default posture is "don't" - **The build is not free.** Each VU carries its own runtime and its own per-VU state; constructing one during the run consumes CPU and memory on the k6 process itself. - **The growth is slow and lossy.** One VU per dropped start, one build in flight at a time. A large ceiling does not rescue an undersized floor; it just stretches the climb. - **It hides the signal.** With a big ceiling, the `Insufficient VUs` warning may never fire, so the only evidence is the `dropped_iterations` counter. - **In Grafana Cloud it is what you pay for.** `maxVUs` counts against the subscription and overrides `preAllocatedVUs`, because the platform must provision for the ceiling whether or not it is reached. - **k6's own docs say so.** The guidance is explicit that in almost all cases you should preallocate the number you need beforehand. ## When a ceiling does earn its keep | situation | why the ceiling helps | what to do afterwards | |---|---|---| | first run of a brand-new scenario | you have no measured `iteration_duration` to size against, and a ceiling keeps the run from collapsing | read the summary, recompute, pin `preAllocatedVUs` | | a modest cushion over a trusted number | absorbs drift in iteration duration without a rerun | keep it small - a fraction of the floor, not a multiple | | very large distributed runs | you are scaling generators deliberately and want a hard per-instance cap | remember both numbers are scaled per execution segment | Everything else is better solved by making `preAllocatedVUs` correct. ## What the ceiling does not buy you It is worth being precise about the guarantees a ceiling does *not* provide: - It does not reserve VUs. Nothing above `preAllocatedVUs` exists until a start has already been dropped. - It does not make growth fast. Builds are serialised, one at a time, in the background. - It does not pin which VU runs which iteration. k6 makes no promise about that in any executor, and an arrival-rate scenario may end up using all of the allocated VUs even when it never needed the whole pool to hold the rate. - It does not change the floor. `preAllocatedVUs` remains what k6 constructs before the clock starts. ## The two shapes side by side The sizing run leans on a deliberate ceiling that is meant to be removed: ```javascript export const options = { scenarios: { exploring: { executor: 'constant-arrival-rate', rate: 500, timeUnit: '1s', duration: '2m', preAllocatedVUs: 50, maxVUs: 400, }, }, }; ``` The committed run keeps the number you measured and no ceiling at all: ```javascript export const options = { scenarios: { committed: { executor: 'constant-arrival-rate', rate: 500, timeUnit: '1s', duration: '30m', preAllocatedVUs: 130, }, }, thresholds: { dropped_iterations: ['count===0'] }, }; ``` The second form is the one to keep. With `maxVUs` unset it equals `preAllocatedVUs`, the pool is fixed, and the threshold turns any shortfall into a failed run instead of a quietly short one. ## The judgment behind the choice The question behind this one is which property of a run you want to be stable. A fixed pool makes the run's resource footprint knowable before it starts: you know how much memory k6 will take, and every repeat of the run begins from the same state. An elastic pool trades that for tolerance of a number you did not measure, and pays for it in dropped starts and in a machine whose own workload changes partway through. On a suite that runs on a schedule, the first property is worth far more than the second - so the mature position is to treat `maxVUs` as a tool used while you are still learning a scenario, and to remove it once you know the answer.