Injection Vocabulary

Chain closed injection steps in one call: constantConcurrentUsers(300) for ten minutes, then rampConcurrentUsers(300).to(50) over a wind-down window, then constantConcurrentUsers(50) if that level must be held. Java, Kotlin, JavaScript and TypeScript register them with injectClosed; Scala uses inject.

Both declare an arrival rate in users per second, not a headcount. constantUsersPerSec(20).during(15) starts 300 users, 20 every second. rampUsersPerSec(10).to(20).during(10) climbs linearly from 10 to 20 a second, starting 150.

setUp registers this simulation's populations, each one a scenario welded to an injection profile, and returns a handle for run-wide settings such as protocols and maxDuration. It must be called exactly once, from the Simulation's constructor.

Gatling has one staircase builder per workload model: incrementUsersPerSec(rateIncrement) and incrementConcurrentUsers(usersIncrement). Both chain .times(levels).eachLevelLasting(duration), plus optional .separatedByRampsLasting(duration) and .startingFrom(x).

Chain two open injection steps in one call: nothingFor for the two-minute gap, then atOnceUsers(500). The gap adds no users and only delays what follows; the surge places all 500 users on one instant and costs no time.

Only virtual users finishing their scenario. Gatling never interrupts a running user to meet a lower target: it withholds the replacement for a finished user while the population is still above the target for the current second, so concurrency falls at whichever is slower — the rate scenarios end, or the declared slope.

A throttle only caps, never raises. Gatling cannot exceed what the injection profile and scenario already offer once pauses are off, so an under-supplied run stays below the ceiling. Enabling one also forces the covered populations' pause policy off.

The entry points sit in different binding layers. Scala's inject infers the model from an implicit InjectionProfileFactory chosen by the step type, while the Java API has no implicits and names the choice instead, as injectOpen and injectClosed.

Chain the second population onto the first with andThen instead of passing both as separate arguments to setUp. Populations listed side by side start together; an andThen child starts only once every user of its parent has terminated.

Levels of 0, 20, 40, 60, 80, 100, 120 and 140 arrivals per second, two minutes each. Omitting startingFrom spends the first two minutes injecting nobody and tops out one increment short, at 140 rather than 160.

Three chain inside throttle(...): reachRps(target).in(duration) ramps the requests-per-second ceiling to a target, jumpToRps(target) steps to it instantly, and holdFor(duration) holds the current value. Declare the chain on setUp or on one injected population.

Only the arrival shape. Both start exactly 1000 users and both occupy 60 seconds. The ramp spaces arrivals evenly; the stress peak follows a smoothed Heaviside curve, so arrivals are sparse at both ends and densest in the middle.

A brand-new virtual user with a fresh id and an empty session, not the finished one looping again. Gatling preallocates no user pool, so a held count fixes how many run at once, never how many run in total.

Two steps in one injectOpen call: rampUsersPerSec(10).to(100).during(Duration.ofMinutes(5)) then constantUsersPerSec(100).during(...). The ramp averages 55 arrivals a second over 300 seconds and starts 16,500 users; the hold starts 100 for every second it runs.

It replaces the evenly spread arrival schedule with randomized intervals drawn from a Poisson process at the same average rate. Scala writes it without parentheses, as .randomized; Java, Kotlin and the JavaScript SDK write .randomized().

The next step begins as soon as every virtual user the current step defines has started, not when those users have finished. A Gatling injection profile is a schedule for launching users, so consecutive steps deliberately overlap.

The stepped-level builders declare no during method. A staircase spells its durations with eachLevelLasting(d) for each level, and optionally separatedByRampsLasting(d) for the ramps between levels.

It was renamed. heavisideUsers became stressPeakUsers in Gatling 3.7, kept only as a deprecated alias, and that alias was dropped in 3.11. Substituting stressPeakUsers is the whole fix; the arrival shape is unchanged.

Not at ten minutes. When the profile's window expires Gatling stops starting replacements, but the run ends only once every user it already started has finished its scenario, so the tail is roughly one scenario iteration long.

Gatling resolves the rate into one whole head-count, shards it across whole seconds, then spreads each second's share over that second's 1000 millisecond slots. Gaps are exactly equal only when every second carries the same share and it divides 1000.

A throttle on setUp is one shared ceiling for the whole run: both scenarios draw on the same per-second budget, first come first served, with no guaranteed split. A throttle per injected population gives each scenario its own ceiling.

Assertions and maxDuration exist only on the setUp handle; protocols, the pause policy and throttling exist on both setUp and each population; andThen exists only on a population. Where a protocol is set in both places, the population's setting wins.

It inserts a linear ramp between levels instead of a hard jump. With a non-zero startingFrom the shape is level-then-ramp, ending on a level with no trailing ramp; with it omitted or set to zero the shape is ramp-then-level, opening with a ramp out of zero.

Decide by what the number is. A rate the test exists to prove belongs in the injection profile, which keeps think time and the request mix intact. A rate that is only a safety limit belongs in throttle.

When the profile stops being uniform. The staircase gives one increment, one level duration and one ramp duration for the whole run, so unequal levels, an uneven progression or a longer dwell at the top all force explicit alternating steps.

Nothing is dropped. Excess requests are buffered in an unbounded in-memory queue inside the load generator and replayed on the next one-second tick, risking an OutOfMemoryError. The throttle profile's total duration also bounds the run, stopping it like maxDuration.

The open staircase builder takes a Double and the closed one takes an Int, and startingFrom follows the same split. Kotlin performs no implicit widening from Int to Double, so the open builder needs a decimal literal.

None of the three interrupts a running user, but they do not come down at the same speed. A ramp keeps replacing finished users against its falling target, so the population follows the declared slope; a step change and the end of the population both shed load at the full completion rate. Ramp when the descent itself is measured or must be gentle; step down when only the lower level matters; end the population when neither is read.

There is no universally right answer, but Gatling fixes the terms: the plain step reruns with an identical arrival schedule, while the randomized one takes its seed from the clock and can never be replayed.