Unexpected load behaviour in Gatling 2.0.0-SNAPSHOT

Gatling (Open-Source)
1

Hi all,

I have found some strange load behaviour when experimenting with the Gatling 2.0.0-SNAPSHOT, to try out the simulation setup/teardown feature (Consider adding setUp and tearDown hooks · Issue #1475 · gatling/gatling · GitHub).

This is my simulation:

val httpProtocol = http
.acceptHeader(“text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8”)
.acceptEncodingHeader(“gzip, deflate”)
.acceptLanguageHeader(“en-US,en;q=0.5”)
.connection(“keep-alive”)
.userAgentHeader(“Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0”)

val POSList = csv(“POS.csv”).random

val random = new java.util.Random

val mosaicHost = “http://"
val TIFHost = "http://”
val headers_graphite = Map( “”“Content-Type”“” → “”“application/x-www-form-urlencoded”“”)

val headers_3 = Map(
“”“Accept”“” → “”“application/json, text/javascript, /; q=0.01"”“,
“”“Origin””" → “”“${mosaicHost}”“”)

val scn = scenario(“TIF”)

.exec(session =>
session.set(“TIFHost”, TIFHost)
)
.exec(session =>
session.set(“mosaicHost”, mosaicHost)
)

.during(15 minutes) {
//open page
feed(POSList)
.exec(http(“TIF SearchPage Mosaic”)
.get( “”“${mosaicHost}/destinations/search/${POS}”“”)
.check(regex(“Travel guide”).exists))

.exec(http(“TIF SearchPage Destinations”)
.get( “”“${TIFHost}/search/destinations/all?pos=${POSUC}&origin=${ORIG}”“”)
.headers(headers_3)
.check(regex(“destinationCode”).exists)
.check(jsonPath(“$…destinationCode”).findAll.saveAs(“destinations”)))

.exec(http(“TIF SearchPage Content”)
.get( “”“${TIFHost}/search/content/${POS}?destinations=${FIRSTCONTENTCALL}”“”)
.headers(headers_3)
.check(regex(“destinationCode”).exists))

.pause(5 seconds, 10 seconds)
//get content
.repeat(random.nextInt(5) + 3) {
exec(http(“Content”)
.get( “”“${TIFHost}/search/content/${POS}?destinations=${destinations.random},${destinations.random},${destinations.random},${destinations.random},${destinations.random},${destinations.random},${destinations.random},${destinations.random},${destinations.random},${destinations.random}”“”)
.headers(headers_3)
.check(regex(“destinationCode”).exists))
.pause(5 seconds, 10 seconds)
}

}

setUp(
scn.inject(rampUsers(1) over (1 second))
).protocols(httpProtocol)

When I run this simulation in the 2.0.0-M3a version I get the following results:

---- Requests ------------------------------------------------------------------

Global (OK=158 KO=3 )
TIF SearchPage Mosaic (OK=27 KO=0 )
TIF SearchPage Destinations (OK=27 KO=0 )
TIF SearchPage Content (OK=27 KO=0 )
Content (OK=77 KO=3 )

When I run the same simulation in the 2.0.0-SNAPSHOT version (mvn archetype:generate -DarchetypeCatalog=https://oss.sonatype.org/content/repositories/snapshots/) I get the following results:

---- Requests ------------------------------------------------------------------

Global (OK=138 KO=2 )
TIF SearchPage Mosaic (OK=7 KO=0 )
TIF SearchPage Destinations (OK=27 KO=0 )
TIF SearchPage Content (OK=27 KO=0 )
Content (OK=77 KO=2 )

As you can see the “TIF Searchpage Mosaic” is somehow executed significantly less than the other requests, without any error being reported.

Are there any changes or known issues in the 2.0.0-SNAPSHOT version that could account for these differences?

Best regards,

Daniel

2

We fixed several caching issues.
Does *TIF SearchPage Mosaic* response have some Expire or Cache-Control
w/Max-Age header? If so, what does it look like?

3

Hi Stephan,

Thanks for your swift reply :slight_smile:

Indeed the TIF SearchPage Mosaic response has a cache-control header

cache-control: max-age=900

So if I understand correct there were caching issues in 2.0.0-M3a and the snapshot version is showing the correct behaviour?

If I would want to simulate a “new user” in each .during iteration, should I then disable caching in gatling.conf or is there a better solution?

Thanks

Daniel

4

Hi Stephan,

Thanks for your swift reply :slight_smile:

Indeed the *TIF SearchPage Mosaic* response has a cache-control header

cache-control: max-age=900

So if I understand correct there were caching issues in 2.0.0-M3a

Yep: Caching mechanism should take into account the Cache-Control header by nremond · Pull Request #1308 · gatling/gatling · GitHub was fixed since 2M3a

and the snapshot version is showing the correct behaviour?

I hope so. You tell me :slight_smile:

If I would want to simulate a "new user" in each .during iteration, should
I then disable caching in gatling.conf or is there a better solution?

Why don't you simply spawn a new one?

5

The reason I created the simualtion like this is that I want my workload to increase gradually and then remain in steady state for a period of time. I have tried to accomplish this with the inject API but did not succeed. Perhaps you can guide me a bit here because the inject api documentation is a bit short:-)

I tried to locate where to disable the caching in the snapshot version but it seems the cache = true entry in the 2.0.0-M3a version of gatling.conf has been removed. What entry should I use now?

cheers

Daniel

6

The reason I created the simualtion like this is that I want my workload
to increase gradually and then remain in steady state for a period of time.
I have tried to accomplish this with the inject API but did not succeed.
Perhaps you can guide me a bit here because the inject api documentation
is a bit short:-)

You can use rampUsersPerSec for a given period, then stick to a
constantUsersPerSec

I tried to locate where to disable the caching in the snapshot version but
it seems the* cache = true* entry in the 2.0.0-M3a version of
gatling.conf has been removed. What entry should I use now?

Only defined on HttpProtocol now: disableCaching. But then, behavior will
be different from real users.

If you really want to go this way, you can clear caches and cookies.
exec(flushHttpCache).exec(flushCookieJar)

7

OK thanks, I will try your inject API suggestion first :slight_smile: