Some help with scenario loop semantics.

Hi,

I have a rather advanced scenario I’m trying to wire up in gatling.
There’s a bunch of custom internal scala code that drives the user-generation and session bits, so I can’t paste the full example here…

I have 2 questions, really…

  1. Is my ideal scenario below possible?
  2. Assuming #1 is not possible, how can I achieve the work-around with the gatling loop semantics?

The scenario uses a static number of users; each user has a quick init phase, which loads an initial value into the session, for use in subsequent calls.
Then it needs to make 1 of 3 calls, at a specific pace, for the remaining duration of the test.
Each rest call returns a value, which is required to make the subsequent rest call.

Consider RestCallA(GET), RestCallB(PUT), and RestCallC(PUT).

Ideally, I would like to make one RestCall every 200ms (per user), with the following semantics:
RestCallB should be called once every 15 seconds.
RestCallC should be called once every 30 seconds.
RestCallA should be called otherwise.

As a work-around, I’m trying to use an ordered set of calls in a couple loops:

RestCall A x 5
RestCall B x 1
RestCall A x 5
RestCall C x 1

I’d like each call in this chain to respect the defined pace, 1 request per 200ms.

Any direction would be greatly appreciated.
Thanks.

  • Jon

Hi Jon,

You can use the pause and repeat loop statement to achieve this.

For instance:

.repeat(5){
exec(RestCall A)}
.pause(5)
.repeat(5){
exec(RestCall B)}
.pause(15)

Thank you.

I did go down the route of repeat/exec/pause, but it doesn’t actually achieve the same pace semantics; latency is not accounted for with the pauses.
It also doesn’t get near the timing requirements of the ideal scenario, so while it works, it doesn’t really test what I want it to.

Another approach I’m playing with, is conditional-clauses hanging off of pace.
doIfOrElse(…) with conditions tied off into my session helpers are extremely promising, but I’m running into problems with nested conditions.

Do you know if its possible to nest doIfOrElse(…) statements? I can’t seem to find any examples of nested conditional or switch statements at all.

I’ve got lots of nested doIf/doIfOrElse/doIfEquals statements with switches somewhere in between in my scenarios, and it is working without any troubles.

Here’s one of my crazy examples:

doIfEquals("${myVar1}", "true"){
  doIf("${myVar2.exists()}"){
    doIf(someCondition){
      doIfOrElse("${myVar3.exists()}"){
        //doing some stuff here
      }{
        doIf(anotherCondition){
          //some more stuff
        }
      }
    }
    .exec(someBlockOfRequests)
  }
}

I did go down the route of repeat/exec/pause, but it doesn’t actually achieve the same pace semantics; latency is not accounted for with the pauses.

Would this help?
https://gatling.io/docs/current/general/scenario#pace

Hi Katerina,

This is exactly what I was trying to do.
However, I run into return-type mismatch problems when using conditions not chained to the previous.

ie: the randomSwitch returns type “B”, not a ChainBuilder, which throws a type-mismatch at build-time.

pace(_.consumerConfig.requestPaceMs.milliseconds)
  .doIfOrElse(_.shouldHeartbeat) {
    ChainBuilder.chainOf(sendHeartbeat()).exec(_.reportHeartbeat)
  } {
randomSwitch(
10.0 -> ChainBuilder.chainOf(commitCursor()),
      90.0 -> ChainBuilder.chainOf(getMessages())
    )
  }

sendHeartbeat(), commitCursor() and getMessages() all return HttpRequestBuilders… which seems that I can’t implicitly convert to ChainBuilders either.
I hope this whole ordeal isn’t because I missed importing some implicit.

I have a workaround at this point which is a hacky switch logic thingy… but it’d be nice to use nested conditions.

Any tips appreciated.
Thanks,

You really shouldn’t use ChainBuilder.chainOf: it’s an internal!
Use exec.