Почему первый запрос Gatling медленнее?

У меня есть сценарий Gatling, в котором я вызываю конечную точку демонстрационного приложения Gatling. Я заметил, что на первый запрос требуется больше времени для ответа. Например:

public class OneEndpointSimulation extends Simulation {

HttpProtocolBuilder httpProtocol = http
        .baseUrl("http://computer-database.gatling.io")
        .acceptHeader("text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8")
        .doNotTrackHeader("1")
        .acceptLanguageHeader("en-US,en;q=0.5")
        .acceptEncodingHeader("gzip, deflate")
        .userAgentHeader("Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0");

ScenarioBuilder scn = scenario("BasicSimulation")
        .repeat(10)
        .on(
                exec(http("request_1")
                        .get("/computers")));

{
    setUp(scn.injectOpen(atOnceUsers(1))
    ).protocols(httpProtocol);
}
    
}

Экран отчета Гатлинга

Вот результат файла Simulation.log:

RUN activitydatabase.OneEndpointSimulation  oneendpointsimulation   1647472671275       3.7.5
USER    BasicSimulation START   1647472672290
REQUEST     request_1   1647472672322   1647472672578   OK   
REQUEST     request_1   1647472672614   1647472672740   OK   
REQUEST     request_1   1647472672742   1647472672867   OK   
REQUEST     request_1   1647472672868   1647472672992   OK   
REQUEST     request_1   1647472672994   1647472673121   OK   
REQUEST     request_1   1647472673123   1647472673244   OK   
REQUEST     request_1   1647472673246   1647472673368   OK   
REQUEST     request_1   1647472673371   1647472673492   OK   
REQUEST     request_1   1647472673494   1647472673616   OK   
REQUEST     request_1   1647472673618   1647472673741   OK   
USER    BasicSimulation END 1647472673748

Есть ли способ ускорить первый запрос?

Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
0
0
32
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Вы ошибаетесь, это ожидаемо.

Из-за того, как устроен ваш тест, первый запрос занимает больше времени, потому что у него больше работы:

  • выполнить разрешение DNS
  • открыть HTTP-соединение

Следующие запросы для этого единственного виртуального пользователя пропустят эту дополнительную работу, потому что:

  • разрешение DNS будет в кеше
  • они будут повторно использовать одно и то же постоянное HTTP-соединение.

Так, например. когда у меня будет такая настройка: setUp(scn.injectOpen(atOnceUsers(1), rampUsersPerSec(1).to(60).during(60), constantUsersPerSec(60).during(Duration.ofMinutes(2)) ).protocols(httpProtocol)); Это означает, что каждый запрос будет выполнять эту работу?

GeorgeGuguli 19.03.2022 15:01

Предполагая, что вы удаляете цикл и вынуждаете perUserNameResolution (чтобы не использовать глобальный кеш DNS Java), да.

Stéphane LANDELLE 19.03.2022 19:25

Да, я бы снял шлейф. Так что в таком случае это означает, что по умолчанию perUserNameResolution выключен, верно?

GeorgeGuguli 20.03.2022 11:24

Другие вопросы по теме

Похожие вопросы