I run two load models:
setUp(scn.inject(rampUsersPerSec(0.1) to (20) during (5 minutes)).protocols(httpConf))
setUp(scn.inject(rampUsersPerSec(0.1) to (30) during (5 minutes)).protocols(httpConf))
In the last case I get a really high spike where number of active users increase from 32 to 650 active users during 30 seconds (!) and then the SUT starts to time out (the WS calls).
Why this sudden spike in number of active users in the last load model? Throttling in my SUT?
At some point you have more active sessions than you can handle. How long time does it take before the number of active sessions takes off?
You should also set an acceptable request timeout to find the limits of your system. Stefan
It takes 4,5 minutes before the spike in active users happens.
I have 'during' 5 minutes as total duration for my scenario.
You mean that if the requirements are i.e 3 seconds, I should set that in the gatling.conf file right?
Maybe try to set duration to 10 mins and then see if I get the same behavior? As in the last 30 seconds or 1 min the spike appears even at 10 min duration?
If I have more active sessions that I can handle from my MBP, is there a way to solve this? Without scaling-out? As I understand this is a problem on the Gatling host not on the SUT? Just asking to learn
The same thing happens if i ‘double’ the duration to 10 mins instead of 5 mins, it happens when the same % of the users have ramped up in some way.
This looks like Gatling, not the SUT.
No, I’m pretty sure Gatling isn’t at fault here. I checked the distribution output and it comes nicely.
What happens is that you reach a failing point where your SUT stops responding or times out, causing your virtual users to live way longer.
In short, this spike is consequence, not a cause.
Great to clarify that!