Non idempotent behavior with same scenario


I have a scenario, without groups, like this :

val searchAndWait = forever() {
.body(StringBody(""“soap env”""))
.header(“Content-Type”, “text/xml;charset=UTF-8”)
.header(“SOAPAction”,“soap binder”)
.pause(20 seconds)


val soc = scenario(“Test”).exec(searchAndWait)

//Injects 60 users, user per user, with a 3 seconds interval. Keeps all users active during 5 minutes (inject duration : 3 minutes)
soc.inject(splitUsers(60) into(atOnceUsers(1)) separatedBy(3 seconds)).protocols(httpProtocol)
).maxDuration(5 minutes)

When I run it twice, I don’t have same request count (2970 vs 2888). I noticed that when I makes some changes on server side, for enhancing response capacities, I have more requests.

How can I be sure that a http fail doesn’t breaks user’s loop ?

Thks !


even though you have a pause of 20 seconds you are asking that gatling loop as fast as the SERVER will permit, ie. co-ordinating with the server.

you don’t want that - you would like that you offer an idempotent load to the server no matter how fast or slow it goes.

So you need to remove that forever() loop around the exec in the scenario.
each injected user starts to look more like a real user now. if the real user does on average 5 searches then loop the search request 5 times, but not forever.

Then in terms of injection, you need to inject at a rate of users arriving at the system boundary.

if I read you split users correctly, something like you start with 1 user per 20 seconds, ramping up to 3 users per second over 60/3 = 20 seconds

rampUsersPerSec(0.05) to 3 during(20 seconds),

then a steady state until the 5 mins max duration

constantUsersPerSec(3) during(280 seconds)

this will produce an exact number of offered requests - the only difference then could be failed requests or similar if you had each user do more than 1 request.


Thks for your answer. I understand I can wrote user injection differently but I went to easiest solution regards to functional specifications.

Hi, no problem, and
Little’s law tells us that if the number of users(N) is fixed and the server response time(R, residence time) is varying, then the throughput(X) (and by implication the arrival rate, λ, in a closed system) will vary also, which is not what you want.

You and most people running api/internet facing tests will have a given user arrival rate, λ, that is an input to the test simulation, so this is something that you want to set. Then the throughput (completed request rate), concurrency(active users, etc depending where you are measuring it) and response time depend on how the system responds to this offered load.

I am assuming you want an idempotent arrival rate, as previously stated.