When it comes to load testing, choosing the right workload model is crucial for accurately simulating real-world user load and understanding how your application will perform under different workloads. In this post, we’ll explore the two primary workload models used in performance testing:
We’ll dive into the differences between them, the scenarios in which each is most appropriate, and how they can impact the results of your performance test.
Workload models define how users interact with your application during a load test. They help simulate production conditions, allowing you to identify potential system performance bottlenecks and optimize resource utilization. Your choice of workload model can significantly affect the behavior of your test execution and the quality of insights.
There are two main types:
Open workload model: new virtual users arrive regardless of how many are currently in the system.
Example: e-commerce or news sites.
Closed workload model: new virtual users are only added as others exit. Example: ticketing platforms or call centers.
Each approach simulates different user activity patterns. Understanding them is key to selecting the right model for your workload analysis and workload planning.
An open system is a system that has no control over the number of concurrent users. Users keep arriving, regardless of the number of concurrent users inside the system.
At some point, if the system starts slowing down, users who are already in the system will take more time to complete their journey, while new users will keep on arriving. Users will then pile up, maybe exponentially, causing your system to eventually crash.
This model is like real-life scenarios where new users can start interacting with the application at any time, independent of the actions or presence of other users.
For example, most public-facing websites behave this way.
In contrast, the closed workload model operates with a fixed maximum number of concurrent users in the system.
Each virtual user performs a series of tasks (or a single task) and then exits the system. Once the system capacity is reached, additional virtual users are queued and only enter as other virtual users exit (1 in-1 out).
This model keeps the maximum number of concurrent users constant, making it easier to simulate a controlled environment where user actions are predictable and manageable.
Your system architecture determines which model you should choose. You should select the model that matches the behavior and the architecture of your system under test in production, even if it means reconsidering how you’ve been doing things to date.
Let’s illustrate this by considering the consequences of selecting the wrong model:
Imagine you have an open system and test it with a closed workload model. If the system under test starts slowing down due to a performance issue, the load injector will reduce the arrival rate to keep the number of concurrent users from increasing. In this case, the load injector and system under test are working together to find a balance, and you have a seemingly successful test.
This balance does not exist in the real world. Your users are not load injectors. In production you do not know how your system will respond to an unbounded increase in users. Thus, the results of your test are meaningless.
If you’re using a closed workload model to test a system that’s actually open, you’re introducing an artificial bias. Don’t do this.
First an important note, you cannot mix workload models in Gatling. The preceding discussion hopefully makes it clear that the purpose and conditions for each test are drastically different and thus it makes no sense to mix the models for any meaningful load testing strategy.
The closed workload injection profile is contained in the setup block in a Gatling script. The following example injects 3 initial users and maintains 3 concurrent users for the test duration.
setUp(
scn.injectClosed(
constantConcurrentUsers(3).during(60)).protocols(httpProtocol)
);
In the following graphs you can see a profile of the user arrival rate and the concurrent users for the preceding code example. Notice how the arrival rate is not constant but the concurrent users is constant during the test!
The open workload injection profile is contained in the setup block in a Gatling script. The following example injects and average of 3 users per second for 60 seconds. The number of users at each injection interval is randomized.
setUp(
scn.injectOpen(
constantUsersPerSec(3).during(60).randomized())
.protocols(httpProtocol)
);
In the following graphs, you can see a hypothetical profile of the user arrival rate and the concurrent users for the preceding code example. Notice how the arrival rate averages 3 users per second but the concurrent users is different and not responsive to the injection rate.
Hopefully this article gives you a better understanding of injection models in load testing. However, the examples are just the beginning. You can achieve much more detailed and complex user scenarios with Gatling’s test-as-code approach.
To keep learning, follow one of our introductory tutorials and then experiment with changing the workload model: