Stop executing the scenario on check errors ?

Gatling (Open-Source)
#1

Hi,

Is there an option for saying that whenever a check fails, the execution of the scenario should stop for this particular user ?

It happens that under load the login fails and then, of course, it doesn’t make any sense to continue.

cheers
Nicolas

#2

Hi Nicolas,

No there isn’t such an option.

However, you’re supposed to simulate user behavior. IMHO, if the login sometimes fails once under load, a typical user doesn’t definitively give up, he… retries (and usually by clicking like crazy)!

Please see:
https://github.com/excilys/gatling/wiki/Retry

You can even add a pause in a “if” block that would only execute if the login failed.

WDYT?

Cheers,

Steph

2012/4/13 Nicolas R. <nicolas.remond@gmail.com>

#3

But if you really insist on stoping this user, you can just the same way surround the rest of your scenario in a “doIf” block:

val scn = scenario(“MyScenario”)

.exec(http(“Login”).post(“loginUrl”).check(status.in(200 to 207).saveAs(“authenticated”)))

.doIf((s: Session) => s.isAttributeDefined(“authenticated”), chain.exec(// rest of your scenario

))

2012/4/13 Stéphane Landelle <slandelle@excilys.com>

#4

The options are :

1/ Continue the execution and ignore the errors
2/ Stop the script for the current user
3/ Retry

By default, we have 1/ but it’s the only one that doesn’t make so much sense to me.

2/ & 3/ are much more interesting to me, but isn’t that boilerplate code decreasing the code readability ?

I think I would like to be able to express this behavior with something like :

.exec(http(“Login”).post(“loginUrl”).check(status.in(200) … ).retry(3).stopOnError

WDYT ?

Cheers
Nicolas

PS: Gatling is such an awesome tool !

#5

Well, my 2 cents is that if you ask people about these 3 options, you will get 33,33% / 33,33% / 33,33%… 328.png

Should “stopOnError” be a global config or specific to a given request?
Should “retry” be applied on a single request or a chain (for example, login is not necessarily a single request process, but can generate multiple requests, like with CAS)?

Complex topic actually…

“retry” and “stopOnError” built-ins could be good ideas, but I’d rather not rush but take time to make sure they’re indeed good ones.
Introducing something in the DSL (which is our public API) is something we want to carefully design. We broke some things between 1.0 and 1.1 because of design mistakes and it was painful for some users.
The best way to have this topic move forward is having other people joining in the discussion (“hey, anybody here???”).

Thanks!

Steph

2012/4/16 Nicolas R. <nicolas.remond@gmail.com>

#6

No rush for me and I fully agree that any DSL changes should be discussed :wink:

Should “stopOnError” be a global config or specific to a given request?
I would think both :stuck_out_tongue:

Should “retry” be applied on a single request or a chain (for example, login is not necessarily a single request process, but can generate multiple requests, like with CAS)?

In case of a chain, I would think that the “retry” only applies on the last request.

More people interested in this topic ?

Nicolas

#7

Hy

any news from this parameter?

For me it will be interesting to provide the possibility of stoping a user whene an error occures. (global parameter StopOnError)

in complex scenarios, it could be great when your using big dataset, to stop thoses who failed beacause of none valid data.

Stéphane

#8

Just surround your whole scenario with a exitBlockOnFail:
https://github.com/excilys/gatling/wiki/Structure-Elements#wiki-exitBlockOnFail

Cheers,

Stéphane

#9

thanks