Workload models define the patterns in which users interact with your system during a test—how they begin, continue, and end their sessions—effectively simulating real-world usage behaviors. Selecting an appropriate workload model is essential because it directly influences the system’s load patterns and, consequently, the nature of the performance metrics you collect. In Gatling, these workload patterns are managed through user injection profiles. These profiles precisely control the timing, volume, and frequency of virtual user generation, allowing testers to replicate a variety of usage scenarios with high accuracy. Let’s explore the two main types of workload models and how they function in detail.
1. Open Workload Model
In an open workload model, new users enter the system at a predetermined rate, independent of the number of users already active. Each user executes the test scenario separately, and their actions do not influence the arrival of subsequent users. This model reflects real-world situations where user volume increases in response to rising demand. An open system does not regulate the number of concurrent users, new users continue to arrive regardless of how many are currently active. If the system starts to slow down, existing users will take longer to complete their tasks while new users keep joining. This can lead to performance bottlenecks, like increased CPU utilization and response times, potentially growing exponentially, and may eventually cause the system to crash.
.png)
How It Works:
✅ Users are added to the system
at a constant rate.
✅
The number of active users increases over time, creating a growing load.
✅
Users who finish their tasks don’t affect
the overall count—new users keep coming in.
Example Scenario: Think of an e-commerce website
during a big sale. More users keep arriving over time, regardless of how long
existing users take to complete their transactions.
Now, let’s see how this works in Gatling:
{
setUp(
scn.injectOpen(
nothingFor(10),
rampUsers(20).during(30),
constantUsersPerSec(20).during(Duration.ofMinutes(60)),
rampUsersPerSec(20).to(1).during(30)
).protocols(httpProtocol)
);
}Breaking It Down:
nothingFor(10) – No users will be injected for the first 10 seconds. This allows the system to get ready before load starts.
rampUsers(20).during(30) – 20 users are added gradually over 30 seconds instead of all at
onceconstantUsersPerSec(20).during(Duration.ofMinutes(60)) – Keeps a steady rate of 20 users per second for 60 minutes. Ideal for testing sustained traffic.
rampUsersPerSec(20).to(1).during(30)
– Slowly reduces the user arrival rate from 20 per second to just 1 per second
over 30 seconds, simulating a gradual traffic drop-off.
2. Closed Workload Model
In contrast to the open workload model, the closed workload model emphasizes maintaining a constant number of active users within the system at all times. As one user completes their set of actions and exits, another user is immediately introduced to keep the concurrency level steady. This model simulates a controlled environment where the total number of users remains fixed, regardless of how long individual tasks take. The pace at which new requests are generated is directly tied to the speed at which users complete their interactions, making response times and system efficiency critical factors.
How It Works:
✅ The overall number of active users stays consistent for the entire duration of the test.
✅ As soon as one user finishes their set of actions and exits the system, another user is immediately introduced to keep the total user count unchanged.
✅ This model replicates environments where a specific, steady number of users are engaged at any given moment—such as customer service call centers, multiplayer gaming lobbies, or collaborative software platforms.
This approach allows testers to observe how a system performs under continuous, controlled pressure, making it ideal for evaluating performance stability and resource management in real-time, user-intensive scenarios.
Example Scenario: Picture a call center where 50
agents handle calls. Each agent deals with one customer at a time, and only
when they finish can they take another call. If calls take longer, fewer calls
are completed per hour.
Here’s how you define a closed workload model in Gatling:
{
setUp(
scn.injectClosed(
rampConcurrentUsers(0).to(100).during(Duration.ofMinutes(1)),
constantConcurrentUsers(100).during(Duration.ofMinutes(100)),
rampConcurrentUsers(100).to(0).during(Duration.ofMinutes(1))
).protocols(httpProtocol)
);
}Breaking It Down:
rampConcurrentUsers(0).to(100).during(Duration.ofMinutes(1)) – Gradually increase the number of concurrent users from 0 to 100 over 1 minute, preventing a sudden traffic surge.
constantConcurrentUsers(100).during(Duration.ofMinutes(100)) – Keeps 100 users active for 100 minutes, maintaining a steady load.
rampConcurrentUsers(100).to(0).during(Duration.ofMinutes(1)) – Slowly
decreases the user count back to 0, simulating a smooth system
cool-down.
Choosing the Right Workload Model
Choosing the appropriate workload model is a foundational step in crafting meaningful and accurate performance tests. The model you select should reflect how users interact with your system in the real world to ensure test results are relevant and actionable. Use an open workload model when you want to simulate scenarios where users arrive independently of system performance—such as during large marketing campaigns, high-traffic websites, or e-commerce platforms, where traffic spikes can happen regardless of server response times. On the other hand, opt for a closed workload model when testing environments where a consistent number of users interact with the system, such as customer support centers, internal enterprise tools, or multiplayer gaming applications.
⚠️ Important Note: Testing a system that operates under an open workload using a closed workload model can lead to misleading performance data. The test won't accurately reflect user behavior or system response under real-world conditions. Always align your test strategy with the actual usage patterns of your application to obtain reliable results.
Final Thoughts
Grasping the concept of workload models—and choosing the right one—is essential for conducting meaningful and effective performance testing. The open workload model is best suited for situations where user traffic varies independently of system performance, such as during seasonal sales, viral marketing events, or public-facing web applications. This model helps simulate unpredictable, real-world traffic patterns. On the other hand, the closed workload model is more appropriate for controlled environments with a steady number of active users, such as enterprise systems, internal tools, or multiplayer gaming platforms.
By understanding the differences between these models, you can craft more accurate and insightful load tests that truly mirror how your system will behave under real-world conditions. This ensures you’re not just testing for performance but preparing your system for success in production environments.
That wraps up our discussion on workload models. Keep testing smart, and may your systems stay speedy and resilient! 🚀 Happy load testing!