How can I build the injection profile for a scenario like this?

[Dinesh Reddy]

Hi,

I have totally 6 test scenarios that need to be run concurrently.

Looking for some help in building up injection profile for a test like below.

200 concurrent threads to be running for an duration of 12 Hours, Users should be increased from 0 to 200 over a time interval of about 1 hour with about 20 users in every 6 minutes.

Thanks In advance,

Regards

Dinesh

[Alex Bagehot]

Hi Dinesh,

First,  so +1 for taking time to think about your workload model before moving on to write the code and run tests.
Great!

if you do have a little time, then consider the following comments. Your wording of the requirement is typical of how other tools constrain the workload model to be stated in terms of concurrent users even if the requirement is throughput. Gatling supports different types of workload model, so it could be confusing if you are not clear in your head with the underlying concepts. So feel free to ask questions...

Forget about Gatling itself for a moment, look a the requirements:

1) we start with a concurrency requirement - 200 concurrent "threads".
This is a fixed number of concurrent users.
If they complete their work faster or slower it doesn't matter. What matters is that each user runs on a dedicated "thread"(or slot in some user population) and once finished a scenario will start immediately  the next one on that same thread.
A concurrency level implies the number of users is fixed, (ignoring ramp up for a minute) none enter or leave the system during the test. They can only work as fast as the system will allow them when starting a new scenario. Result of this is that arrival of new requests can be delayed/throttled or "backed off" as the system under test performance degrades.
One of the best descriptions of this user population is a call center where a fixed number of CSR's take calls and process them against the system. There is no pause between users as the CSR's will want to process as many calls as possible.
==>
This is a "closed" model. Because each notional "thread" loops around in a closed loop executing scenarios from start to finish, back to back.

2) then it moves on to have a requirement for "20 users in every 6 minutes".
(I assume, for the benefit of making things clear that ) this is an arrival rate requirement. ie how often will users arrive at the boundary of the system under test.
The same user arrival rate could cause wildly different concurrencies depending on the time the user spends in the system.
If the users take longer than 6 minutes in the system the concurrent users could increase out of control, unbounded.
An arrival rate of users also typical implies in theory that the users (a) are acting independently, (b) come from an infinite population of possible users.
Most public internet websites fit this model. It is also the simpler(from a workload/gatling pov) and more prudent model from a risk perspective.
==>
This is an "open" model because the users arrive and once finished, depart never to return again (hopefully another day for good sales, but for the purposes of the load test, never). There is no feedback loop at the user level.

First you need to choose which model your users best fit into.
Then in Gatling you can choose which inject method.
http://gatling.io/docs/2.0.0/general/simulation_setup.html
those that say "...PerSec()" (per second) imply an arrival rate and therefore => open model,
the others that don't, imply a one time injection of users, and implemented with a looping scenario => closed model

If it did turn out to be open, then the "20 users in every 6 minutes" converts to 1/18 users per second, or around 0.056...

Gatling supports a mixed workload, open and closed in the same simulation, as the inject is set per scenario.

Thanks
Alex

--
You received this message because you are subscribed to the Google Groups "Gatling User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gatling+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dinesh Reddy]

Thanks Alex for the detailed write up about the approaches and suggestions. I went through the given link and defined my injection profile as follows.

  setUp(

      scnLaunchApp.inject(rampUsers(Integer2int(Integer.getInteger("users",200))) over (60 minutes),

          constantUsersPerSec(200) during(12 hours)),

      scniosDeviceApps.inject(rampUsers(Integer.getInteger("users",200)) over (60 minutes),

          constantUsersPerSec(200) during(12 hours)),

      scnBrowseAndInstallApp.inject(rampUsers(Integer.getInteger("users", 200)) over (60 minutes),

          constantUsersPerSec(200) during(12 hours)),

      scnForcedHeartBeat.inject(rampUsers(Integer.getInteger("users", 200)) over (60 minutes),

          constantUsersPerSec(200) during(12 hours)),

      scnDownloadMCM.inject(rampUsers(Integer.getInteger("users", 200))over (60 minutes),

          constantUsersPerSec(200) during(12 hours))

      ).protocols(EMMPerfConfig.httpConf)

With this I am going to ramup the 200 users users in the first one hour and after that I will continue to have 200 requests per second for 12 hours.

Thanks

Regards

Dinesh

[Alex Bagehot]

Hi Dinesh,

Assuming you determined your users are not fixed and therefore an open model, I thought you wanted 20 users per 6 minutes? which is 0.056 users per second.

rampUsers(Integer2int(Integer.getInteger("users",200))) over (60 minutes)

It may not be obvious but rampUsers(N) is a closed model construct.

In this closed model situation you want a total of 200 users in the system at the end of the ramp up(and you don't do any inject after than assuming some steady state time). So it will inject 200 users in 60 minutes. Ie. 0.056 users per second. then stop injecting.

constantUsersPerSec(200) during(12 hours)

will inject 200 users per second for 12 hours, ie. 3571 times (200/0.056) higher rate than the ramp up phase....

to ramp the users in an open model use:

rampUsersPerSec(10) to(20) during(10 minutes), // 6

Because your rates are low you may need to be careful of the starting number (actually not sure if it can start with 0).

ie.

rampUsersPerSec(0.01) to(0.056) during(60 minutes)

Thanks,

Alex