Concurrent requests with pause


I’m looking a way to execute two http requests concurrently but with a pause before second request execution.

It can be described by the following fragment:


Only solution I found for concurrent requests execution using existing API is the code below. But I can’t specify pause for a second request:

exec(http("req0").get(...).resources(http("req1").get(...), http("req2").get(...)))

Could you please advise how I can add pause between concurrent requests using existing Gatling API?

It shouldn’t be hard. You can do something like this

object MyRequests{

val request1 = exec(http(req1).get(…)))…

val request2 = exec(http(req2).get(...)))...


val user1= scenario(“myScenario”){

val user2= scenario("myScenario"){



Sorry, I misread your question.
Just put .pause(2 seconds) after exec(), you should be good. Updated previous code also.

Thank you. Good solution.

But these requests are executed by different users in different sessions. It is problematic for my scenario because I have key-value retrieved from previous responses and saved in user session storage.
So I could use this approach only if there is a way to share key-value between user sessions.

See also
And #2336

Thank you, Alex.

“I guess for emulating requests from JS code, pauses make sense.”

Exactly. I need pause between async requests to emulate JS code logic. Does it make sense to reopen the issue?


I am just wondering why the simple pause between two exec() not solve yours issue.

Something like

exec(....get(req1..). Pause(10)
exec(....get(req2..). Pause(10)

Hi Abhinav,

I need to execute second request concurrently with first one. Exec() calls request synchronously which means it will complete getting response on this request from server.
I’m working with Ajax application in my case and requests must be asynchronous.

Resources are constrained by connections (default is 6 connections per host).
What would the behavior of such pauses be?

Answering on question: What would the behavior of such pauses be?

Let’s consider simple UI with two buttons. First button binded to long running GET request, let’s call it ‘run/start’. The second button is ‘cancel’ and it is binded to another request which can ‘cancel’ already running process.
End-user starts a long-running process and he/she can cancel/stop process pressing ‘cancel’ button after several seconds from pressing first button.

So test scenario looks like two asynchronous calls with pause between it.

In a nutshell, I do not believe that stock Gatling DSL can support this scenario. Typically, Gatling waits for a request to finish before continuing with the execution. You want to violate this principle.

The only way you could simulate this, in theory, if Gatling supports it, is to specify a per-request timeout. If the default Gatling request timeout is 60 seconds, then you would have to specify a timeout of 5 seconds for that request. Then, after 5 seconds, the request would “fail” and you would initiate the cancel request.

But that’s a hack. It messes with your reports. And it sounds more like functional testing than load testing. Pulling off this use case will require you to write custom code, I’m afraid. And I can’t tell you what that code would look like, I can only tell you that it will probably not be Gatling DSL.