Gatling Simulations and Injection Profiles

Gatling’s injection profiles are its equivalent of k6’s executors and JMeter’s Thread Group settings — the mechanism for defining exactly how virtual users (or, for some profiles, request arrivals) ramp up and sustain over a test’s duration.

Common injection profiles

• atOnceUsers(n) — injects all n users simultaneously, useful for testing an instantaneous spike.
• rampUsers(n).during(duration) — ramps n users linearly over the given duration, the most commonly used basic profile.
• constantUsersPerSec(rate).during(duration) — open-system, arrival-rate-based injection: a steady rate of new user sessions starting per second, regardless of how long each session’s actions take — Gatling’s equivalent of k6’s constant-arrival-rate executor.
• rampUsersPerSec(rate1).to(rate2).during(duration) — ramps the arrival rate itself between two values over time.
• heavisideUsers(n).during(duration) — injects users following a Heaviside-step-like distribution (more users injected toward the middle of the duration), useful for more naturally modeling some real-world traffic shapes than a strictly linear ramp.

Closed vs open system in Gatling’s terms

The same modeling distinction covered throughout this site applies directly here: rampUsers/atOnceUsers model closed-system (user-count-based) behavior, while constantUsersPerSec/rampUsersPerSec model open-system (arrival-rate-based) behavior. Choosing between them should follow the same logic as choosing between JMeter’s plain Thread Group and an Arrival Thread Group, or k6’s VU-based versus arrival-rate executors.

Combining multiple scenarios and profiles in one simulation

setUp(
  browsingScenario.inject(rampUsers(200).during(2.minutes)),
  apiScenario.inject(constantUsersPerSec(50).during(5.minutes))
).protocols(httpProtocol)

Like k6’s multi-scenario support, Gatling lets you run multiple scenarios with independent injection profiles concurrently within a single simulation — modeling a realistic mix of traffic types rather than one uniform load shape.

Pauses and think time

Gatling’s .pause(duration) (fixed) or .pause(min, max) (randomized within a range) between scenario steps models think time directly within the scenario definition, similar in purpose to JMeter’s timers but expressed as part of the readable scenario DSL itself rather than a separate GUI element.

Throttling: capping overall request rate

Gatling’s throttle directive lets you cap the overall request rate across a simulation independent of how many users are injected — useful for deliberately holding a test at a specific maximum rate regardless of injection profile specifics, similar in intent to JMeter’s Constant Throughput Timer but configured at the simulation level.

Choosing the right profile for your question

Same guidance as elsewhere on this site: decide first whether you’re answering a “how does the system handle this many concurrent users” question or a “how does the system handle this arrival rate” question, then pick the injection profile family that actually matches — ramping/atOnce for the former, constant/ramping-per-second for the latter.

Takeaway: Gatling’s injection profile vocabulary is rich enough to model almost any realistic load shape precisely — the main discipline required is picking the profile that actually matches the real-world traffic pattern you’re trying to represent, not just whichever one is most familiar.