Across a suite of Gatling simulations, would you declare the waiting policy on each pause call, on the injected population, or on setUp, and how would you decide?

Gatling lets the same waiting policy be expressed in three different places, and they are not interchangeable in the way a reviewer, or a future maintainer, has to read them. The mechanism is fixed — a `force` argument on a call beats a policy on the population, which beats a policy on `setUp`, which beats the built-in constant default — so the question is entirely one of where you *choose* to put it. ## What each placement buys **On `setUp`.** One line, at the top of the file, that a reviewer reads before anything else. It applies to every population and every chain the simulation composes, including chains pulled in from a shared library. It is the right home for a decision that is a property of *the run*: this run models waiting behaviour, or this run is a flat-out probe with `disablePauses()`. **On the injected population.** Nearly the same methods exist on a population — `disablePauses()`, `constantPauses()`, `exponentialPauses()`, `uniformPauses(...)`, `customPauses(...)` and the generic `pauses(type)`; only `normalPausesWithStdDevDuration(...)` and `normalPausesWithPercentageDuration(...)` are `setUp`-only, and a population reaches that distribution as `pauses(normalPausesWithStdDevDuration(...))`. So one `setUp` can hold a browsing population with realistic waits and a probe population with none. This is the right home when the decision is a property of *the user profile* rather than of the run, and it is the only placement that lets two profiles differ inside a single run whose results you want to read together. **On the individual `pause(...)` call.** A `force` argument overrides everything for exactly one wait. It is precise and it is nearly invisible: nobody reading `setUp` will learn that one wait somewhere in a two-hundred-line chain opts out. Reserve it for waits that are not think time at all — a poll interval, a settle time before a read-after-write check — where the value is part of the protocol, not part of the user model. ## How I would decide 1. **Default to `setUp`, and put it there even when it agrees with the default.** Writing `constantPauses()` explicitly costs one line and turns an implicit assumption into something a reviewer can see and a diff can change. A reader should never have to know the framework default to know what the run did. 2. **Move it to the population only when two profiles in one run genuinely differ.** If they differ, they belong in one run so their results share a clock; if they do not, splitting the policy across populations is noise. 3. **Use a `force` argument only for waits that are mechanically required.** If you find yourself forcing more than one or two per simulation, the run-wide policy is wrong and you are patching it call by call. 4. **Do not let a shared chain library declare a policy.** Chains meant for reuse should carry durations and nothing else, so that the simulation composing them owns the interpretation. A library chain that forces its own pause type will surprise every simulation that reuses it. 5. **Pin it, whatever you choose.** Two runs whose waiting policy differs are not comparable, and the policy is invisible in the report — so an unstated policy is a difference nobody will spot when they compare last week's numbers with today's. ## Two traps this decision walks into * **There is no configuration key for it.** Nothing in `gatling.conf` sets the pause type; it exists in the simulation's code or not at all. A per-environment switch therefore has to be built by hand in the simulation, and once it is, the run's behaviour depends on something the report does not show. If you build one, make the run description say which way it was set. * **"Disable all waiting" is not one switch.** The pause type is consulted only when Gatling builds a `pause` action. `disablePauses()` leaves every `pace` interval and every `rendezVous` barrier exactly where they were. A simulation that leans on `pace` to hold a rate does not become a flat-out probe when you disable its pauses — it keeps its pacing and loses only the think time, which is a third behaviour that nobody asked for and that the report will not distinguish from either intended one. ## The shape I would land on | decision | where it lives | |---|---| | does this run model waiting at all | `setUp`, always written explicitly | | do two user profiles wait differently | the injected populations | | is this particular wait a protocol requirement | a `force` argument on that call | | does a reusable chain need a policy | it does not — the composing simulation owns it | None of this is enforced by the framework: every one of these placements compiles and runs. The value of choosing one deliberately is that a year later the answer to "why did this run produce that number" is one line at the top of the file rather than a search through the chains.