Peak concurrent users and session length

Hi,

A project I am working on has Gatling load tests running whereby we throttle the TPS. Within the scenario a random user id is acquired from a range of id’s (0 - 10,000,000) for each request. This is done to represent the size of the user base. I have noticed though this isn’t an accurate representation of the daily usage as only a certain number of users log in on a day and there is a subset of users at any given time (PCU - peak concurrent users). I am wondering if there is a way to specify more configuration to the scenario to represent this. I am thinking this must be a fairly common situation that applications would need to be tested against.

If the PCU was 1 million and the average session length was 20 minutes then I would think it could be something like rampUsers(1000000).over(20 minutes).for(20 minutes). The .for(20 minutes) would mean that each user would be destroyed after 20 minutes and a new user would be created. That new user could be associated to a random user id in the range of id’s.

Anyone else have feedback on something they have built that might work similarly?

If the PCU was 1 million and the average session length was 20 minutes then I would think it could be something like rampUsers(1000000).over(20 minutes).for(20 minutes). The .for(20 minutes) would mean that each user would be destroyed after 20 minutes and a new user would be created. That new user could be associated to a random user id in the range of id’s.

Your “for” would be a during loop in your scenario.

Load model you select depends on your objective. Most of the time, I am usually trying to find choke points in applications. Daily averages are great place to start but I extrapolate based on this information and business requirements.

In your case, if you are objective is to see how the application scale on consistent load then increase duration of tests for a longer period. If you want to test performance then increase throughput. Have certain users come through open model (constant users per sec) and some through closed model (during).

Just my $.02. Hope it makes sense.

Hi Shawn

I would challenge ( in a hopefully helpful way) the way the requirements and or problem statement is constructed.

For many years the mainstream load test tools have technical constraints that meant that they can only set the load intensity in terms of concurrent users.

This has caused the users of these tools some major headaches on occasion, myself being one of them.

Clearly your users are not repeating their work as you explicitly state that a user is “destroyed” after 20 mins. Having an outer loop in the scenario is therefore not wanted.

In addition you are using throttle which is a bad code smell unless there is the justification to require it.

It would be worth resting in terms of the throughput you want.

Ie
1 million users / 20 minutes / 60 seconds = ? Users per second

=> constantUsersPerSec

If a portion of your users log on on then separate them out into a different scenario and inject them at the lower rate.

We have seen problems with high connection rates with this approach. There is a setting to sheet connections between users if that is the case. Probably the least worst option in that situation.

Thanks
Alex