Gatling 3: Closed Workload Model Support

(By © Flickr/ kfcatles)

The closed workload model is a strategy to face performance issues of a web application. We often see it in the ticketing industry, for instance. With Gatling 3 (check out our latest release candidates and feel free to give some feedback!), our users are now able to test this kind of injection profile. The closed workload model is one of the new features in Gatling 3 (see our post about all the new features in Gatling 3).

But let’s take a look at how it works first!

Open vs Closed Workload models

An open system is a system that has no control over the number of concurrent users. Users keep on arriving whatever the number of concurrent users inside the system. At some point, if the system starts slowing down, users that are already in the system will take more time to complete their journey while new users will keep on arriving. Users will them pile up, maybe exponentially, causing your system to eventually crash.

Most public facing websites behave this way.

On the contrary, closed system implement some feedback and queueing system so when the system is at full capacity, arriving users are pushed into a queue and can only enter the system when another user exits. large ticketing platforms behave this way.

In short:

• open workload model: you define the arrival rate of new virtual users; number of concurrent users inside the system is a consequence of the response times and the journey duration and you have no control over it
• closed workload model: you define the number of concurrent users effectively inside the system; arrival rate is a consequence and you have no control over it

Picking the proper model

If you’re using a closed workload model to test a system that’s actually open, you’re introducing an artificial bias. If the system under test starts slowing down, the load injector will reduce the arrival rate to keep the number of concurrent users from increasing. So load injector and system under test will work together to find a balance. But this balance does not exist in the real world, and the results of your test are meaningless.

You must pick the model that matches the behavior and the architecture of your system under test in production, even though it means reconsidering how you’ve been doing things so far.

Using the new Closed Workload Model

The injection profile DSL from Gatling 2 is still here, and it generates an open workload where you control the arrival rate of the virtual users in your scenario.

Instead, if you want to shape the number of virtual users inside your system, you can use the new constantConcurrentUsers and rampConcurrentUsers from the new DSL introduced in Gatling 3.

scn.inject(
  rampConcurrentUsers(0) to(100) during(10 seconds),
  constantConcurrentUsers(100) during(10 seconds)
)

Beware that you can’t mix open and closed injection steps in the same injection profile.

Meta injection steps

Gatling provides you with all the necessary injection step elements so you can build complex injection profiles.

Moreover, we now provide meta injection steps, ie helper that would generate built-in sequences of injection steps.

Open workload model version:

// generate an open workload injection profile
// with levels of 10, 15, 20, 25 and 30 arriving users per second
// each level lasting 10 seconds
// separated by linear ramps lasting 10 seconds
scn.inject(
  incrementUsersPerSec(5)
    .times(5)
    .eachLevelLasting(10 seconds)
    .separatedByRampsLasting(10 seconds)
    .startingFrom(10)
)

Closed workload model version:

// generate a closed workload injection profile
// with levels of 10, 15, 20, 25 and 30 concurrent users
// each level lasting 10 seconds
// separated by linear ramps lasting 10 seconds
scn.inject(
  incrementConcurrentUsers(5)
    .times(5)
    .eachLevelLasting(10 seconds)
    .separatedByRampsLasting(10 seconds)
    .startingFrom(10)
)

Distributing Users with FrontLine

If you try to build a distributed test manually, you’ll most likely have to split the target load amongst your injectors.

When running a distributed load test with Gatling FrontLine, you only have to define the global target load and FrontLine will take care of distributing it for you.

We are still in the process of releasing Release Candidates of Gatling 3. Download Gatling now, and give us some feedback before we release the stable version of Gatling 3! We need you!

Stephane from the Gatling team

Related resources

You might also be interested in…