In a Gatling closed injection profile, what actually brings the number of concurrent users down when a step ramps from 300 to 50?

## The rule, stated the way Gatling's own documentation states it Gatling's injection reference carries a warning next to the closed model: *"Ramping down the number of concurrent users won't force the existing users to interrupt. The only way for virtual users to terminate is to complete their scenario."* That sentence is the whole subject. A closed injection step declares a **target**, and Gatling only ever moves toward that target in one direction — **up**. ## The correction loop, measured A closed population is driven by a tick. Once per second the load generator: 1. works out which injection step the run is currently inside, from the accumulated step durations; 2. evaluates that step's target for the current moment — `300` for a hold, an interpolated integer for a ramp; 3. subtracts the number of users currently in flight; 4. if the difference is **positive**, starts that many new users, spread across the coming second; 5. if the difference is **negative**, does **nothing at all**. There is no branch that stops a user. Separately, whenever a virtual user finishes its scenario, Gatling checks the current target again and starts one replacement immediately if concurrency is below it — which is what makes the hold a hold. During a ramp-down that check fails while the population is still above the ramp's current interpolated target, and starts succeeding again the moment completions pull it below — so a ramp the scenario can keep up with is held on its declared line, and only a ramp steeper than the completion rate leaves the population trailing above it, shrinking one user at a time. It is worth being precise about which of the two mechanisms does the work on the way down. During a monotone ramp-down the tick above never fires step 4: the immediate replacement on each completion tops the population back up the instant it dips under the falling line, so the tick always finds the population at or above the target and its difference is never positive. The per-completion replacement is the whole story for a ramp-down; the tick's job is reaching a level and following a ramp **upward**. ## What that means for 300 down to 50 Take `rampConcurrentUsers(300).to(50).during(Duration.ofMinutes(2))` after a ten-minute hold. The *declared* target falls by roughly two users per second. The *measured* concurrency falls at whichever of those two is slower — that declared slope, or the rate scenarios end: | scenario iteration length | what the concurrent-user chart shows over the two minutes | |---|---| | a few seconds | the measured curve tracks the declared ramp closely | | about one minute | the curve lags, then catches up near the end of the window | | three minutes | almost nothing happens; the run is still near 300 when the ramp ends | So the profile you wrote and the curve the run draws can be two different lines, and the size of the gap is a property of your **scenario**, not of your injection profile: the measured decay is the slower of the declared slope and the rate scenarios complete, and the gap opens only when completion is the slower of the two. This is the single most common surprise in Gatling's closed model, and it is why a wind-down window shorter than one scenario iteration is decoration. ## Why Gatling refuses to interrupt A virtual user is in the middle of something: an HTTP request in flight, a pause, a loop iteration, a group that has not closed. Cutting it off would produce a request with no response, a half-written group timing and a session that never reached its exit hook — measurements that would then pollute the statistics the run is there to produce. Letting the scenario finish keeps every recorded request attributable to a complete journey. The trade is predictability of *timing* for integrity of *data*, and Gatling chose the data. ## The same rule at the end of the run The end of the last step is a ramp-down to zero in disguise, and it behaves identically. When the profile's clock runs out, Gatling stops topping up and marks the population as fully scheduled, but the run does not end until every user it already started has finished. A ten-minute profile whose scenario takes three minutes is a thirteen-minute run at worst. If the wall clock matters — a CI job with a timeout, for example — bound it with `maxDuration` on `setUp`, which ends the run gracefully rather than crashing it. ## Making the curve match the profile There is no interrupt switch in the closed injection DSL, so every remedy works on the other side of the equation: - **Make the wind-down window longer than one scenario iteration.** If an iteration takes a minute, a five-minute ramp from 300 to 50 will track; a thirty-second one will not. - **Shorten the scenario** — fewer actions per iteration, or a loop body that ends sooner — so users turn over more often and the population can respond faster. - **Accept the trail and say so in the report.** For many runs the wind-down is not the part being measured, and a curve that lags for a minute costs nothing. - **Do not expect a steeper ramp to fix it.** The slope is a real lever, but only up to the completion-rate ceiling: once the target falls faster than scenarios end, completion is the binding constraint and steepening buys nothing. In the three-minute-iteration case above it is already binding, which is exactly why the curve sits at 300. ## Common mistakes - Reading a lagging concurrency curve as a broken load generator or a saturated injector. - Declaring a wind-down shorter than a single scenario iteration and expecting it to be honoured. - Assuming the profile's total declared duration is the run's duration. - Believing a lower target eventually forces users out if you wait inside the same step — it never does; only completion removes a user.