Your Gatling run must sit at 200 requests per second across two scenarios, so how would you decide between declaring that rate with throttle and declaring it in the injection profile?

Gatling gives you two ways to make a run sit at 200 requests per second across two scenarios, and they are not equivalent. One expresses the rate as **demand**, in the injection profile; the other expresses it as a **limit**, with `throttle(...)`. Choosing well means knowing which guarantee you are actually buying. ## The two candidates ```java // demand: the profile produces the rate setUp( browse.injectOpen(constantUsersPerSec(120).during(Duration.ofMinutes(10))), checkout.injectOpen(constantUsersPerSec(80).during(Duration.ofMinutes(10))) ).protocols(httpProtocol); // limit: the profile produces more, the ceiling trims it setUp( browse.injectOpen(constantUsersPerSec(200).during(Duration.ofMinutes(10))), checkout.injectOpen(constantUsersPerSec(200).during(Duration.ofMinutes(10))) ).protocols(httpProtocol) .throttle(reachRps(200).in(Duration.ofSeconds(30)), holdFor(Duration.ofMinutes(9))); ``` Gatling's own documentation is not neutral between them. It says that if your virtual users perform only one request each you *should* use an open-model injection step such as `constantUsersPerSec`, and that a throttle over a multi-request scenario will leave you without *"any means of controlling which request gets executed"*. ## What each side actually costs | dimension | rate in the injection profile | rate via `throttle(...)` | |---|---|---| | think time | preserved as declared | deleted, unless a pause forces its own pause type | | which requests make up the rate | follows the scenario as written | whichever request asks first | | excess traffic | none: the profile produces the rate | parked in an unbounded injector buffer | | run duration | bounded by the profile or `maxDuration` | also bounded by the throttle profile's length | | protocols covered | all of them | HTTP and JMS only | | fractional rates | yes | no — the target is an integer | Read that table as one sentence: a throttle buys a hard total and pays for it with the shape of the traffic underneath. ## The questions worth asking before you decide 1. **Is the number a requirement or a safety limit?** If the test exists to prove the system handles 200 requests per second, the rate is the *subject* of the test and belongs in the profile, where the report's arrival-rate chart will show it. If the number exists to stop a shared environment being flattened, it is a limit, and a throttle is the right shape. 2. **Does the mix matter?** A scenario that issues several different requests gets no guarantee about which of them fill the ceiling. If the ratio of reads to writes is part of what you are testing, a throttle will not preserve it and per-population throttles only move the problem down one level. 3. **Do the pauses matter?** A throttle deletes every pause that takes the population's pause policy; only a pause given an explicit pause type, such as `pause(Duration.ofSeconds(5), constantPauses)`, survives it. If the scenario's think time is part of the workload you agreed with the product team, throttling changes the workload, not just its ceiling. 4. **How far above the ceiling will the profile run?** The gap is parked in the load generator's heap with no bound. A ceiling near the offered traffic is cheap; a ceiling an order of magnitude below it is a memory failure waiting to happen. 5. **Is every protocol in the scenario covered?** Throttling reaches HTTP requests and JMS. A scenario that also opens WebSockets will exceed the ceiling on that traffic silently. ## A defensible default For most teams the rule that holds up is: **express the rate you want in the injection profile, and reserve `throttle(...)` for a guard rail.** The profile is the declaration a reviewer can read, the report charts it directly, and nothing about the scenario is silently rewritten. A throttle then earns its place only in the narrow cases it was built for — a single-request scenario, a shared environment with a contractual cap, or a run where an accidental overshoot would be expensive. Where a throttle is allowed, write the rule down as three constraints rather than as a permission: * The ceiling must be within a small factor of what the injection profile offers. * Every population's throttle profile must be the same total length, since the shortest one becomes the run's clock. * Results from throttled runs are not compared against results from unthrottled ones, because the pause policy differs between them. ## What you should not claim for it A throttle is a property of the **load generator**, not of the system under test. It says what Gatling will send; it says nothing about what the target can absorb, and it is not a substitute for whatever limiting the service itself does. Keeping that distinction crisp is most of the judgement this decision needs.