ETag help with Gatling

Gatling (Open-Source)
#1

Hi all,

I am having trouble getting Gatling to behave as I would expect using ETag caching.

My scala simulation file is as follows. It very simply executes an http query twice with the same virtual user:

`
class EtagSimulation extends Simulation {
object QueryForBook {
val feeder = csv(“books.csv”).circular
val query = exec(http(“Request”).get("/"))

}
val httpConf = http
.baseURL(“https://xxxxxx:xxxx/xxx/xxx/xxx?type=YYYY&acct.abc=1234”)
val scn = scenario(“ETag Load Test”).exec(QueryForBook.query).exec(QueryForBook.query)
setUp(scn.inject(atOnceUsers(1)).protocols(httpConf))

`

The initial response sent from the server contains the ETag header:

HTTP response: status= 200 OK headers= Content-Type: [text/plain] ETag: [**456**] Cache-Control: [public] Transfer-Encoding: [chunked] Server: [Jetty(8.1.0.RC5)]

Gatling recognizes the ETag and caches it:

22:59:24.162 [DEBUG] i.g.h.c.CacheHandling$ - Setting Etag 456 for uri https://xxxxxx:xxxx/xxx/xxx/xxx?type=YYYY&acct.abc=1234

Session:

Session(ETag Load Test,6561610672275210974-0,Map(gatling.http.cookies → CookieJar(Map()), gatling.http.cache.etagStore → Map(https://xxxxxx:xxxx/xxx/xxx/xxx?type=YYYY&acct.abc=1234 → 456)),1410299962423,58,OK,List(),)

However, the next request that it sends to the server does not contain the expected If-None-Match tag containing the ETag:

`
Request DefaultHttpRequest(chunked: false)
GET /xxx/xxx/xxx?type=YYY&acct.abc=1234 HTTP/1.1
Connection: keep-alive
Host: aaa.bb.cc.dd:xxxx
Accept: /
User-Agent: Gatling/2.0

`

Please advise. Thanks!

#2

Hi,

I tried to reproduce with the following url: http://platform.twitter.com/embed/timeline.295a00bf5122128e332d25515711dbbd.2x.css
Gatling behaved as expected and properly sent the expected If-None-Match.

Which version of Gatling do you use?
Is there anything tricky with your url, such as being redirected?

Stéphane

#3

Hi Stéphane,

The problem occurred with RC4. I was able to fix the problem. It appears to be caused by a quirk in Gatling. The problem occurred when I had the entire URL in the httfconf baseURL. When split it up and added only the host to the baseURL, moved the resource to the get("/…") method, and then added the two query params using the queryParam method, it worked.

For example, broken setup:
baseURL(“http://1.2.3.4/re/source?param1=a&param2=b”)
get("/")

Working setup:
baseURL(“http://1.2.3.4”)
get("/re/source").queryParam(“param1”, “a”).queryParam(“param2”, “b”)

#4

I exactly use the same set up as the one that’s broken for you:

val req = http(“timeline”).get(“http://platform.twitter.com/embed/timeline.295a00bf5122128e332d25515711dbbd.2x.css?type=YYYY&acct.abc=1234”)
.header(“Accept”, “text/css,/;q=0.1”)
.header(“User-Agent”, “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.94 Safari/537.36, value”)

val scn = scenario(“Etag”).exec(req).exec(req)

setUp(scn.inject(atOnceUsers(1)))

I’d really like to be able to reproduce :frowning:

#5

Strange… my setup is very simple. Should be easy to repro. Other differences in the set up are:

  1. The host is specified using IP:port.
  2. The service is using SSL. Key manager and trust manager config with certficate files and passwords are specified in the conf file.

https://123.456.789.10**:5555**/

#6

Providing me with your url would really help.

#7

Sorry, it’s not public. I’m not able to provide you with the URL. Even if I could, you wouldn’t be able to access it outside of this network. Did you try running the test with IP:port specified with https/SSH certificates?

#8

That wouldn’t matter.
Maybe it has something to do with url-encoding.

By any chance, it there any special character in your query params?

#9

I think the URL did have a special character at the end… Possibly from when I pasted it in. The character wasn’t visible in vim, but I did notice something in the Gatling logs. The problem may have been resolved when I retyped out the URL manually (instead of pasting).

#10

Maybe…

Sorry, I can’t really help if I can’t reproduce.
Maybe someone else will someday report a similar issue.