Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/gatling/gatling.io-doc/llms.txt

Use this file to discover all available pages before exploring further.

Choosing the correct workload model is one of the most consequential decisions in load test design. Get it wrong, and your simulation will measure something fundamentally different from what your real system experiences under production traffic — giving you false confidence or misleading bottleneck analysis. Gatling explicitly separates open and closed workload models at the API level, making the choice explicit rather than accidental.

​
Open vs Closed Workload Models

Real-world systems fall into one of two behavioral categories when under load:

Closed Systems

The number of concurrent users is capped. A new user can only enter the system once another exits. Throughput is bounded by user count × service rate.

Open Systems

Users arrive at a given rate regardless of how many are already being served. The system has no mechanism to queue or block arriving traffic.

​
Closed System Examples

A closed system enforces a maximum concurrency ceiling. New arrivals must wait or are rejected when the system is at capacity:
  • A call center where all operators are busy — callers queue until an agent is free.
  • A ticketing website with a virtual waiting room — users are held until capacity is available.

​
Open System Examples

An open system accepts traffic continuously. Response times may degrade, but users keep arriving:
  • Most public websites — browsers send requests regardless of current server load.
  • REST APIs called by external services — clients retry or fire-and-forget without awareness of server capacity.
Do not use a closed workload model if your system actually behaves as an open one.When you model an open system with a closed injection profile, your test is fundamentally broken. Here is why: as the system starts to struggle and response times climb, virtual users take longer to complete their journeys. This reduces the arrival rate of new users (because old users are stuck), which in turn reduces the load just when you most need to observe the system under stress. Your simulation is measuring a fictional, self-limiting system — not the one in production.

​
Choosing the Right Model

Ask this question: does my system push back excess traffic, or does it accept all arrivals?
System characteristicModel to use
Queueing or rate-limiting at the entry pointClosed (injectClosed)
Users arrive regardless of server stateOpen (injectOpen)
Open and closed workload models are mutually exclusive within a single injection profile. You cannot mix injectOpen and injectClosed steps for the same scenario.

​
Further Reading

For a deep academic treatment of this topic, see Schroeder et al., “Web Workloads and Why They Are Different”, USENIX NSDI 2006: https://www.usenix.org/legacy/event/nsdi06/tech/full_papers/schroeder/schroeder.pdf To learn how to configure injection profiles in Gatling, see the Injection reference.

Build docs developers (and LLMs) love

Get started for freeTalk to us