[2.0.0-M3a] Order of requests in test not as required

Gatling (Open-Source)
1

Hi. I found strange behaviour in my test.

My scenario look like this:

val scn = scenario(“load-test”)
.exec(
http(“1”)
.put(_ => getURL)
)
.pause(2000 milliseconds)
.exec(
http(“2”)
.post(xml_url)
)

It means first is need to send request “1”, get answer and check it.
When wait 2 sec.
When send request “2”, get answer and check it.

In Gatling log it seems totally fine
13:32:35.980 [INFO ] i.g.c.a.UserStart - Start user #848
13:32:35.980 [INFO ] i.g.h.a.HttpRequestAction - Sending request ‘1’: scenario ‘load-test’, userId #848
13:32:38.082 [INFO ] i.g.h.a.HttpRequestAction - Sending request ‘2’: scenario ‘load-test’, userId #848

But on our Apache balancer first request was accepted only on 13:32:38
/var/log/apache2/ssl_access.log: - - [24/Dec/2013:13:32:38 +0400] “PUT /api/v2/… HTTP/1.1” 200 2587 “-” “GATLING/2.0”
And second request was accepted as expected with some ms delay after sending.

Aproximately 30% of all first requests has similar problem. First request accepted at same time or even later then second request.

Can it be Gatling problem or it has some to do with our Apache or network ?

2

No, reordering cannot happen on Gatling side.

Beware that time measurement is always tricky. For example, even if you use something low level such as Java’s System.nanotime, you always get a chance that different CPU cores won’t be absolutely in sync.

3

Ah, sorry, the title of your post maybe mislead me.
As I get it, you don’t describe a reordering, but the pause not being performed, right?

4

I don’t sure that happened.

Yeah, it’s sort of pause trouble…

Main problem that some first requests late or even can be accepted by our balancer after second requests and it completely ruin test logic … But from gatling perspective seems that all working because in log number are right … Honestly, I don’t know where to find a trouble…

5

How about the novel approach of blaming the load balancer or the application under test first, rather than shooting the messenger (gatling)? :slight_smile:

6

OK, so Gatling cannot be the culprit if request2 sometimes arrives before request1.
If it were only a matter a the pause not happening, I could have maybe blamed the old Akka HashWheelTimer impl, but there’s no way Gatling could interchange requests.

7

Thanks for answers.

I don’t even think to blame Gatling ) It’s incredibly great tool.

And Happy New Year to all of your)

8

Well, this situation is a first, and sometimes it can be difficult to find out where the problem is. Like every program, Gatling can be buggy too.

Thanks for your kind words and happy new year too!

Stéphane