The order of http requests affect the response time

[dom]

I have created a Spring Boot application and I am using the plugin gatling-maven-plugin version 4.3.7 and the dependency gatling-charts-highcharts version 3.9.5.

I have implemented a simulation by extending the Simulation class from the package io.gatling.javaapi.core.

I have a simple scenario where I make 2 requests to different endpoints of a REST API:

    ScenarioBuilder testScenario = scenario("Testscenario")
            .exec(http("GET endpoint1")
                    .get("/endpoint1")
                    .check(status().is(200)))
            .exec(http("GET endpoint2")
                    .get("/endpoint1")
                    .check(status().is(200))); 

The response time for both endpoints is roughly 50ms when making the http request from my machine. All tools I have used so far to verify that (Postman, Insomnia, ThunderClient for VS code) confirm the reponse time.

But in my gatling simulation I have the following problem:
I’m running the simulation by ramping up 100 virtual users over 1 minute. After running the simulation a report is generated from the gatling-charts-highcharts dependency. In the report I can see the response times for the two requests to endpoint1 and endpoint2, respectively. But whatever order I use, the first http requests always has a considerably higher response time. So if I call endpoint1 first and then endpoint2, then the average response time for the request to endpoint1 is rougly 1000 ms and the average response time for endpoint2 is about 50 ms.
Now if I change the order in the gatling simulation and send the http request to endpoint2 first, then the average response time for endpoint2 is 1000 ms and for endpoint1 the average response time is 50 ms.

But if I send only one request to one of these two endpoints, then I get an average response time of 50 ms, as it should be.

Does anyone know what could cause that problem and how to fix it?

[slandelle]

Impossible to tell if you don’t provide a reproducer as requested when posting here.

Then, if you’re using the default configuration, for a given virtual user, the first request against a host will get the DNS resolution + TCP connect + TLS handshake overhead while the second one will simply reuse the keepalive connection.

Postman, Insomnia, ThunderClient for VS code

Do these tools include DNS resolution + TCP connect + TLS handshake overhead in the response times they report?

[dom]

Thank you for your response.

I will provide a reproducer during the weekend and check if the other tools include DNS resolution + TCP connect + TLS handshake overhead in the response times and answer that.
.

[slandelle]

You might also want to check if these tools are using a shared connection pool for the whole test instead of isolating per virtual user.
For a functional testing tool, it would make perfect sense.
For a load testing too, it doesn’t if you’re trying to simulate a fleet of distinct users.

[dom]

Thank you!

In the meantime I was able to confirm a similar response time in ThunderClient when the DNS resolution + TCP connect + TLS handshake overhead is taken into account.

In my Gatling load test scenario I am now sending a “starter” request to an health endpoint of the API to account for the DNS resolution + TCP connect + TLS handshake overhead and afterwards I am sending the actual requests of interest to the two endpoints. Now I am getting the same response times for the two endpoints as with the tools that do not include the DNS resolution + TCP connect + TLS handshake overhead.

[slandelle]

Then, understand that these times are part of the response time that your actual users experience.
And these steps can absolutely break under load as your edge struggles to keep up.