In a Gatling run, what happens to requests the throttle ceiling will not admit yet, and what ends a run whose throttle profile is shorter than its injection profile?

A Gatling throttle never rejects a request. When the current second's budget is spent, the request is **parked**, and Gatling comes back for it on the next tick. Understanding that queue, and understanding that the throttle profile also fixes when the run ends, are the two things that turn a throttle from a surprise into a tool. ## How the second is spent The throttler wakes on a fixed one-second tick. On each tick it recomputes the current ceiling from the throttle profile, allocates that many permits, and then: * A request that arrives while permits remain is **sent**, and the permit count is incremented. * A request that arrives with no permits left is **appended to a buffer**. * On the next tick the buffer is replayed first against the fresh permits, and anything still over budget is buffered again. Within a tick the permitted requests are not fired as a burst. Gatling divides the second by the current limit and spaces the requests across it, so a ceiling of 200 becomes roughly one request every five milliseconds rather than 200 at the top of the second. ## The buffer is unbounded — and that is the risk That buffer is a plain growable collection with no capacity limit and no drop policy. Gatling's own documentation flags the consequence in a warning: *"all excess traffic gets pushed into an unbounded queue, possibly resulting in an OutOfMemoryError if your normal throughput is way higher than the normal one"*. The failure mode is entirely **inside the load generator's JVM**, not in the system under test: the target never sees the parked requests, so it cannot push back on them, and the injector's heap absorbs the whole excess. The arithmetic is easy to get wrong. A simulation that offers 1,000 requests per second under a ceiling of 200 parks 800 every second. Over a ten-minute hold that is roughly half a million buffered parked request closures, each holding the work still to be done, and every one of them expects to be sent eventually. Nothing sheds, nothing expires, and nothing warns you before the heap goes. Practical consequences: 1. **Size the ceiling near the offered traffic, not far below it.** A throttle is for trimming an overshoot, not for holding back an order of magnitude. 2. **Watch the injector, not just the target.** A throttled run that dies with an `OutOfMemoryError` is reporting a load-generator problem, and the run's results are void. 3. **Do not read a throttled run's response times as the system's.** A request parked for several seconds before it is sent is not timed from when it was parked, so the deferral is invisible in the report. ## The throttle also ends the run The second surprise is that a throttle profile is a **duration limit**. Gatling sums the durations of the profile's `reachRps` ramps and `holdFor` plateaus — `jumpToRps` contributes nothing — and folds that total in with any declared `maxDuration`, taking the **minimum**. When that limit expires the controller stops the run gracefully, with the message *"Run stopped on maxDuration(...) reached"*. Two things follow that regularly confuse people: * A simulation that never wrote `maxDuration` can still stop with a `maxDuration` message, because the throttle supplied the limit. * The limit is computed over the **whole run**, including every population's own throttle. If one population carries a two-minute throttle profile while the others are injecting for an hour, the entire run ends after two minutes. | declared | effective run limit | |---|---| | `maxDuration(30 min)` only | 30 minutes | | `throttle(reachRps(200).in(30), holdFor(5 min))` only | 5 minutes 30 seconds | | both of the above | 5 minutes 30 seconds — the minimum wins | | a 2-minute throttle on one population out of four | 2 minutes, for all four | ## Building a profile that does not surprise you Make the throttle profile's total duration match the run you intended, and let the injection profile be the thing that is generous. In the example below the ceiling ramps for thirty seconds and holds for nine and a half minutes, giving a ten-minute run, while the populations are injected for ten minutes as well — so the throttle bounds the run at precisely the moment the traffic was going to stop anyway, and nothing is cut short.