why not allow to use gatling DSL in before/after hooks

Gatling (Open-Source)
1

Hello,

Gatling 2.17 docs say that:
You won’t be able to use Gatling DSL in there, as it’s only intended for load test. You can only use your custom code.

I just wonder why such restriction exists? I leverage before/after hooks to create/delete data, actual load test must test retrieval only as reading predominates in production. Without Gatling DSL, I have to write a lot of boilerplate code with Apache HTTP Client:
`
class ManagerStressTest extends Simulation {

before {
val client = HttpClientBuilder.create().setDefaultCredentialsProvider(provider).build()

val post = new HttpPost(…)

val mapper = new ObjectMapper()
val entity = new StringEntity(mapper.writeValueAsString(new User(userId))
post.setEntity(entity)
val response = client.execute(post)

client.close()
}

after {
val client = HttpClientBuilder.create().setDefaultCredentialsProvider(provider).build()

val response = client.execute(new HttpDelete(s"${baseURL}/manager/api/${userId}"))

client.close()
}

val scn = scenario(“READ Scenario”)
.exec(session => session.set(“userId”, userId))
.exec(http(“readingUser”)
.get("/manager/api/${userId}")
.headers(Map(“Content-Type” → “”“application/json”"")))

setUp(scn.inject(atOnceUsers(System.getProperty(“nbUsers”).toInt)).protocols(httpConf))
}
`

Using Gatling DSL instead of plain-vanilla Apache HTTP Client would be more elegant.

2

I just wonder why such restriction exists?

   1. Because the current implementation doesn't support it. We would have
   to disable the stats module there.
   2. Because that's a Pandora box: some people would want only one single
   user there, some tons of them.
   3. Because you can do that in dedicated simulations.
   4. Because, database restore scripts/images are probably a better way to
   deal with system under test set up and tear down

I leverage before/after hooks to create/delete data, actual load test must

test retrieval only as reading predominates in production. Without Gatling
DSL, I have to write a lot of boilerplate code with Apache HTTP Client:

Use AsyncHttpClient instead which is the HTTP engine Gatling uses
underneath (I'm the dev there), at least you don't have to import another
library.

3

With Gatling 3.0 this is even more interesting, because asynchttpclient is no longer shipped:

  1. No reason to deny this
  2. Why you do not make clear restrictions what is possible and what not
  3. THIS is the real question. You can not make sequential scenarios within a Simulation (which can be a pre-setup) nor you can reliable transfer parameters between Simulations
    I would love to get an answer to at least point 3
4

Yeah, I’m also interested in getting more details on answer 3. How I can do such thing, could you please provide some example ?
Or is there any way I can set Gatling session variable in before hook ?

5

you can set session variables through an feeder (which is just an iterator). But my question is about orchestration of several feeder / sequential scenario’s and a functionality like “nothingFor” which will wait for the previous scenario. This is required, since i have setup steps which are configrable and might take longer than specified with “nothingFor”. If i still use “nothingFor”, i will start several sessions which are just looping and wait to start (which can be very heavy if we talk about millions of sessions)

6

Same issue here. Using “nothingFor” is odd to use.
What i think we are all asking is to be able to use the same Gatling API as if it were a plain HTTP client.

To explain, currently i am using the very asynchttpclient that Gatling was using in version 2 in order to initialize a specific scenario.
But asynchttpclient’s API is not as good as Gatling’s. With the Gatling’s DSL i can create a scenario with multiple steps, pass variables across with the steps (using session) and eventually perhaps in my last step, gather all needed data and save to a file. And i could do that for as many users as i wished.
One example is obtaining an initialization file filled with auth tokens, which may be complicated (more than one step) to obtain for a given user or number of users. Those tokens are ephemeral, so they have to be re-generated at every run or so. Once the initialization file is saved (no stats needed up to this point), then the very scenario I really wanted to load-test is run, and the stats are generated just for that.

I think what Stephane is saying (is he?) is that this issue should be dealt with by separate logic and scripts responsible for initializing (in the case of the before hook), or by docker containers that can then be easily disposed of, thus relieving yourself from the difficult task of reinstating (after hook) previous db state or such.
But what i found in practice is that it is much easier to use Gatling’s DSL to instead write those initialization scripts, unless of course initialization data is huge, convoluted and database heavy.

Unsure if we are getting outside of Gatling’s DSL responsibilities, but thought i explained a practical use case.
Without this, it is harder to create smaller scenarios exercising only portions of more convoluted ones.

Max

7

In short:

  • not how Gatling is implemented (builders)
  • not how before is implemented (arbitrary code, not Gatling DSL evaluator)
  • not a priority for us
  • would require a LOT of work
8

Hi

I’m running into an issue where I want to perform PUT request to update a resource but before that I need to have the resource created once so I can later on perform update to this created resource multiple times(i.e.multiple virtual users only for PUT http call). I’m wondering how can I perform below in before { } ?
I tried this way but it fails.

http(“Create operation”)

  .post(/resource).header(..).body(...) in 

Looking at your example I'm confused what library should I use since we can't use DSL in before hook. Could you guide what dependency to include in order to use HttpClientBuilder?