[Gatling 2] Inject users over constant time until ceiling

Gatling (Open-Source)
1

Hey there again,

I’m looking for some guidance on how I’d go about implementing a new injection step that would look something like the following:

scn.inject(constantUsersPerSec(5) to (100 users))

Where we inject a constant number of users per second (5) until we get to 100 active user sessions, where the injector will continue to inject to maintain (roughly) that ceiling. From the looks of it, the current injectors are required to give a known duration, where as I’d prefer this to just go indefinitely until all users in the feeder are completed.

Thanks.

CONFIDENTIAL COMMUNICATION:

This email may contain confidential or legally privileged material, and is for the sole use of the intended recipient. Use or distribution by an unintended recipient is prohibited, and may be a violation of law. If you believe that you received this email in error, please do not read, forward, print or copy this email or any attachments. Please delete the email and all attachments, and inform the sender that you have deleted the email and all attachments. Thank you.

2

Hi Rob,

First, have a look at how the ConstantRateInjection class is definited :

https://github.com/excilys/gatling/blob/master/gatling-core/src/main/scala/io/gatling/core/controller/inject/InjectionStep.scala#L50

Then, the class you want may look like this :

case class ConstantRateForGivenUsersInjection(rate: Double, users: Int) extends InjectionStep {
val duration = (users / rate).seconds
val ramp = RampInjection(users, duration)
override def chain(iterator: Iterator[FiniteDuration]): Iterator[FiniteDuration] = ramp.chain(iterator)
}

And you can just use it this way :

scn.inject(ConstantRateForGivenUsersInjection(5.0, 100))

Add a DSL on top of that if you want, but that’s not necessary.

Cheers
Nicolas

3

“until we get to 100 active user sessions”
Beware, the injection engine is not currently aware of the current active user count.

4

ah oui - je raconte n’imp.
au lit.

5

Rob, as I said, the injection scheduler is not currently aware of the number of alive users.
I still have to be convinced that it’s a must have (bring pros).

For example, if constantUsersPerSec(5) to (100 users) works as you described, how can you be sure that you indeed reach 100 concurrent users at some point in time? What if your users finish too fast? You have to ensure this yourself. And if you do that, you can just use the regular constantUsersPerSec: constantUsersPerSec(5) over(20), right?

WDYT?

Stéphane

6

Hey Stéphane,

You’re correct: There are no assurances that you’ll ever meet the ceiling, but this comes down to test design. However, in some test designs constantUsersPerSec(5) over (20) won’t be satisfactory.

For example, we use Gatling to run platform load tests via the UI (e.g. we simulate 2000 people shopping at the same time, ramped over 5 minutes). It takes roughly 25 minutes for the test to complete. What we’re looking to now is to overlay another UI load test (taking a different path, using a new or old system, etc) that is given constant, known load so we can predict the impact of the two paths “interacting”.

There’s two solutions that I see right now, one is a long-running cUPS(5) over (30 minutes) or chaining a ton of smaller-duration injectors together, manually predicting when the load will need a boost back up to our normal. Doing the first will easily move us out of an acceptable deviation from our expected constant, whereas the latter introduces too much fragility to the test and will require more maintenance.

Hope that helps.

7

Hey Rob,

That’s something we’ll have to think about and design properly, meaning for M5.
Could you please open a feature request?

Cheers,

Stéphane

8

Done, thanks Stéphane! https://github.com/excilys/gatling/issues/1647

CONFIDENTIAL COMMUNICATION:

This email may contain confidential or legally privileged material, and is for the sole use of the intended recipient. Use or distribution by an unintended recipient is prohibited, and may be a violation of law. If you believe that you received this email in error, please do not read, forward, print or copy this email or any attachments. Please delete the email and all attachments, and inform the sender that you have deleted the email and all attachments. Thank you.

9

Thanks!