Hi,
I wrote a very simple simulation that:
- Hits a shop landing page
- Hits a shop category landing page
I configured my simulation to run with 5 users and wanted it to run for 10 minutes. Surprisingly, duration based testing with a set number of users wasn’t the easiest thing to do. I am new to Gatling so I am sure there is a good reason for that… I digress.
I ran the simulation and configured it to repeat 10 times instead of 10 minutes. I was puzzled by the results. I was expecting that with 5 users * 10 iterations that each transaction would be repeated 50 times. That was not the case, this is my question, why is that? Screenshot to illustrate the results is attached. From my observation, it appears that the transaction that isn’t executing 50 times (like all the others) is the automatic redirect? I did google this observation but didn’t find anything that helped/worked.
Thank you for your time and support.
Ouray
Your shop uses Expires or max-age based caching.
OK, and can you recommend a workaround? I have tried .disableCaching, but clearly that doesn’t control the stuff you are talking about?
Yes it does. But then, don’t you want to simulation proper user behavior (that have caching enabled)?
Yes, I certainly do want to simulate proper user behaviour. However, when I compare the same test repeated in two other test tools Gatling is the only one that only executed the automatic redirect 5 times instead of 50 times.
Are you saying that because Gatling detects that the same user is hitting the redirect, it detects that technically the new iteration is still be repeated by the same “user” and therefore Gatling sees no need to repeat the request. The request does contain j-session related data, which is normally issued for each new unique HTTP session.
Gatling comes with defaults that simulate browser instances, which is the most common use case. Hence with caching enabled.
Other tools defaults are their own opinion.
Gatling sees no need to repeat the request because the response headers told it to cache it and to not request again (until expire). Just like a browser.
This has nothing to do with j-session cookie. Please search the internet for more explanation about Expires and Cache-Control HTTP headers.
OK, I see your point and agree. My lack of appreciating the Expires header (which was present in the 302 response) was caused by the other tools not obeying it in the same way that Gatling does.
I am happy with your explanation, thank you for your time!
