Check adds time to response time

Hello.
If I try to make request for 150 users:

def authenticationRandomStringRequest2: ChainBuilder = {
builder
.exec(http(“authentication random string 2”)
.post(“authentication/randomString”)
.header(
“x-header”,"""{“appCertificateFingerprint”:“AE:FF:1E:19:73:8E:A3:0B:75:99:8B:24:71:46:A4:A6:66:D0:59:BC:1C:00:16:ED:FD:11:FF:87:2E:CD:92:BB”,“deviceFingerprint”:“loadtest”,“deviceId”:“loadtest”"}"""
)
.check(jsonPath("$").saveAs(“randomStringResponse”))
)
}

And get result where response time for this request is less then 0.1 s (see attach simulation-20210810100107750 without check.png )

but if I make this requests and add check

def authenticationRandomStringRequest2: ChainBuilder = {
builder
.exec(http(“authentication random string 2”)
.post(“authentication/randomString”)
.header(
“x-header”, “”"{“appCertificateFingerprint”:“AE:FF:1E:19:73:8E:A3:0B:75:99:8B:24:71:46:A4:A6:66:D0:59:BC:1C:00:16:ED:FD:11:FF:87:2E:CD:92:BB”,“deviceFingerprint”:“loadtest”,“deviceId”:“loadtest”"}"""
)
.check(jsonPath("$").saveAs(“randomStringResponse”))
.check(
jsonPath("$")
.transformWithSession((string, session) => {
var valueToSign = “”
for (
parent ←
defaultJsonParsers
.parse(string)
.findParents(“randomString”)
.toArray
) {
if (
!defaultJsonParsers.parse(parent.toString).has(“attachmentId”)
) {
valueToSign = defaultJsonParsers
.parse(parent.toString)
.findValue(“randomString”)
.asText()
}
}
IitUtils
.getInstance()
.signData(
Base64.getDecoder.decode(session(“key”).as[String]),
password,
valueToSign
)
})
.saveAs(“signedDataParameter”)
)
)
}

Then response time in report becomes much bigger (see simulation-20210810100834711 with check.png)

In both cases I use fiddler to capture traffic, and in both cases I see, that response time is about 0.1 s.

Gatling documentations says that "The response time is the elapsed time between the instant a request is sent and the instant the complete response is received:

The beginning of the request’s sending is the instant when the connection to the target host has been established or grabbed from the pool.
The end of the response’s receiving is the instant when the whole response (status, headers and body) has been received by Gatling"

But in this case I think, that Gatling adds time of check calculation to response time.

May be you can tell me, what I do wrong, and how can I resolve this issue?
Thank you in advance.

Ilya Dikun

Hello,

I can guarantee we measure the time between the time the request is sent to the IO framework and the time the IO framework hands over the last response buffer.

As required in this group’s terms:

  • Make sure you’re using an up-to-date Gatling version
  • Provide a Short, Self Contained, Correct (Compilable), Example (see http://sscce.org/)

Complying to those requirements both saves us time and makes it possible for us to investigate your problem.

Regards,

Hello.
I have reproduced the issue using the demo project.

What I have done:

  1. Took example code from GitHub - gatling/gatling-gradle-plugin-demo: Showcase of the Gatling Plugin for Gradle

  2. Run this scenario for 100 users
    results for request_2 you can see on the picture:

  3. Added proxy to httpProtocol :
    .proxy(
    Proxy(“127.0.0.1”, 8888)
    .httpsPort(8888)
    )

to capture traffic by fiddler

  1. Added to the second request (“request_2”) check:

.check(css(“html”).transformWithSession((string, session) => {
Thread.sleep(3000)
}))

Instead of using third party libraries, like in example above, I used Thread.sleep(3000)
Listing of BasicSimulation.class you can find in “BasicSimulation with check.txt”

  1. Run the scenario for 100 users
    results for request_2 you can see on the picture:

At the same time, the fiddler showed that there was no request longer than 0.6 s

When I run the scenario with check for 10 users - there is no problem.

I hope you can tell me what this problem may be related to, and what I can do to avoid it.

Best regards, Ilya Dikun

вторник, 10 августа 2021 г. в 15:40:36 UTC+3, Stéphane Landelle:

BasicSimulation with check.txt (2.01 KB)

Sorry but your reproducer is broken. It’s utterly wrong to call Thread.sleep there.

I do this only to simulate the work of third-party libraries in this block of code

среда, 11 августа 2021 г. в 15:18:49 UTC+3, Stéphane Landelle:

Sorry, but I can only help if you provide a correct full reproducer showing what you exactly do.
What I can say for sure is that your code is suboptimal as you’re parsing from String to JSON, serializing back to String, and then parsing to JSON again.