Need to understand Gatling Group Values from Simulation Log - Numbers not adding up

Gatling (Open-Source)
1

Hi:

I am trying to understand the results I am getting from the Group() function to aggregate groups of requests in Gatling.

I understand that the Group() function will aggregate requests from the first requestStartDate of the group to the last responseEndDate of the Group.

If I look at the timestamp associated to each Group in the Simulation.Log, those timestamps match nicely that definition.

However, Gatling reports a Response Time in (ms) for groups that is off most of the time.

For example, in the example shown below taken from the Simulation.Log, Gatling calculates 40755ms for Login Group, which is way higher than the subtraction of the two timestamps in the same Group Login record.

1447634196231 – 1447634187678 = 8553

For BatchUpdate group, I see another discrepancy, but in this case, Gatling reporting a lower value (6177) than the real one (10237)

For the third group shown (CommitG), the value obtained from Gatling seems to match closely the calculated (sustracted) value.

batchupdate 7936755033588976644-0 GROUP Login 1447634187678 1447634196231 40755 87 0 OK

batchupdate 7936755033588976644-0 GROUP CommitG 1447634202818 1447634206468 3635 15 0 OK

batchupdate 7936755033588976644-0 GROUP BatchUpdate 1447634196232 1447634206469 6177 27 0 OK

GroupName Gatling Value Real Substracted Value Comment

Login 40755 8553 Gatling value is way higher than Real

CommitG 3635 3650 About the same

BatchUpdate 6177 10237 Gatling value is lower than Real

I need to know if this is a known bug with Gatling 2.1.5, if so, if there is a fix for it, or if these “response times values” have a different meaning.

I also need to know the meaning of the last 3 columns (87,0,OK for Group Login above)

Any information will be appreciated,

Rene

PD: This is another example from the second user in the simulation:

batchupdate 7936755033588976644-1 GROUP Login 1447634217700 1447634222808 27726 87 0 OK

batchupdate 7936755033588976644-1 GROUP CommitG 1447634229319 1447634232276 2949 15 0 OK

batchupdate 7936755033588976644-1 GROUP BatchUpdate 1447634222808 1447634232276 5435 27 0 OK

GroupName Gatling Value Real Substracted Value Comment

Login 27726 5108 Gatling value is way higher than Real

CommitG 2949 2957 About the same

BatchUpdate 5435 9468 Gatling value is lower than Real

2

Did you check the group timings definition? http://gatling.io/docs/2.1.7/general/timings.html#groups

3

Yes I read that definition, but the information is not helping understanding the results.

I need to know if there is any relation between the two time stamps for each Group record in the simulation log and the next value that follows (which I presume is the calculated Group response time)

For instance, one group that has some embedded resources included, if I take the maximum response timestamp and subtract the minimum request timestamp from that group, I get about 8 seconds.
If I sum all the response time for all requests and resources in the group, I get about 17 seconds.

However, Gatling is reporting a response time of about 40 seconds for the group.

Using any of these definitions, or combination, I cannot explain the result.

Response Time

The response time of a group is the cumulated response times of each individual request in that group.

Note

When dealing with embedded resources (inferred or explicitly set), the behaviour is slightly different : as resources are fetched asynchronously,

the cumulated response time for embedded resources starts from the beginning of the first resource request to the end of the last resource request.

I need to be able to explain it to in order to move forward with using Gatling in our group.

Your help will be appreciated,

Rene

On Tuesday, November 17, 2015 at 4:25:52 PM UTC-8, Stéphane Landelle wrote:

4

Please provide a full reproducer: an actionable simulation (so not one where urls and such a anonymised).

5

Hi:

Since this application is within the company intranet, and not accessible from outside, and due to company policies, I cannot provide an actionable simulation.

I simplified the code to a single user login followed by a logout, so I can rule out many other variables and illustrate the problem.
Gating reports that entire simulation took 3 seconds as shown in Screenshot at the bottom of this message.

If I add all the response times of all requests and resource redirects generated by the application in the Loging group, it adds up to 6751ms

However, the same screenshot shows Gatling reporting 34964ms (34.9 seconds) for Loging Group alone.

This is the piece of code I used, but with a fake base URL, userid, etc

This code is based from the code obtained with Gatling Recorder

I know that this is “my problem” to solve, but I don’t know what else to do. I feel lost with these group results I am getting, and I really need it to move forward with our project.

Any clues as to what may be causing that result? Or tips for a workaround?

I will really appreciate any help you can provide, even when I cannot provide an actionable simulation…

Rene

import scala.concurrent.duration._

import io.gatling.core.Predef._
import io.gatling.http.Predef._
import io.gatling.jdbc.Predef._

class BatchSimulation8 extends Simulation {

val httpProtocol = http
.baseURL(“https://j4beta.xyz.com”)
.inferHtmlResources(BlackList(), WhiteList())
.acceptHeader(“image/png,image/;q=0.8,/*;q=0.5”)
.acceptEncodingHeader(“gzip, deflate”)
.acceptLanguageHeader(“en-US,en;q=0.5”)
.connection(“keep-alive”)
.contentTypeHeader(“application/x-www-form-urlencoded; charset=UTF-8”)
.userAgentHeader(“Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)”)

val headers_0 = Map(“Accept” → “text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8”)

val headers_2 = Map(“Accept” → “/”)

val uri1 = “https://j4beta.xyz.com:443/cara”

val scn = scenario(“BatchSimulationScn”)
.group (“Loging”) {
exec(http(“Loginr”)
.post("/cara/j_acegi_security_check")
.headers(headers_0)
.formParam(“j_username”, “xyz123”)
.formParam(“j_password”, “xyz123”)
.formParam(“submit”, “Login”))
}

// Logout
.exec(http(“Logout”)
.get("/cara/logout.req?logoutCode=1")
.headers(headers_0))

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

6

Can you reproduce with latest snapshot? https://oss.sonatype.org/content/repositories/snapshots/io/gatling/highcharts/gatling-charts-highcharts-bundle/2.2.0-SNAPSHOT/gatling-charts-highcharts-bundle-2.2.0-20151117.135644-379-bundle.zip

You’ll have to change “connection” into “connectionHeader” (or simply remove it)

7

Hi:

I tried the new bundle (2.2.0), but I am having similar problems with the group results.
Attached find screen shots I took,

Rene

8

Sorry, I can’t reproduce. It might have something to do with your redirects.
Without a reproducer, I can’t really help.

You could maybe try to build one with some public website that exhibits the same behaviour.

9

Hi Rene/All,

Even we are facing the same issue where the group numbers are not adding up to the subsequent redirect requests. Were you able to figure out reason behind this?

Thanks
Anand

10

Hi,

I am seeing the similar behaviour with latest version of gatling 2.3.0. I see there more variation when redirect requests are present in group.

Any help will much appreciated and its blocking us from moving further with using Gatling as replacement for Jmeter?

Regards,
Vishal Kadam

Regards,
Vishal Kadam