Jmeter5.2.1: тестовые прогоны занимают больше времени в Jmeter

Question

Я работаю над переносом скриптов из Performance Center в Jmeter5.2.1. В рамках этой миграции мы используем тот же функциональный поток, что и в Performance Center. Мой сценарий состоит в том, что пользователи, входящие в веб-приложение, выполняют 10-15 итераций, а затем выходят из системы.

Это мой план тестирования.

TestPlan
--ThreadGroup1
      --Once Only Controller (login of users)
      --Loop Controller      (10 Iterations)
              HTTP1
              HTTP2
              HTTP3
              .
          .
      --Once only Controller (logout of users)
      --csv Config data ( username/password)
      --csv config data( unique data for the loop controller)

При таком подходе я замечаю, что время, затрачиваемое на прохождение теста в Jmeter, намного больше, чем у нас в центре производительности (я позаботился времени на обдумывание и добавили аналогичные значения) Почему мой тестовый запуск выполняется медленно в Jmeter?
Последовательный ли контроллер l oop? Это означает, что в данный момент времени он может выполнять только один запрос?
Если не контроллер l oop, какие другие опции нам нужны для моего сценария.
Если я включаю разные группы потоков, перенос JSESSIONID должен выполняться в потоке группы, которая не является лучшей практикой для этого.

Обновление:

Сравнение настроек центра производительности и настроек Jmeter Ниже приведены настройки в Jmeter.
Настройки группы потоков:

TestPlan:
HTTP Cook ie менеджер в группе потоков
CSV-файлы данных в плане тестирования
Один только счетчик для входа и выхода из системы
L oop Контроллер для итераций.

HTTP-запрос По умолчанию: (Даже без проверки получить все встроенная и параллельная загрузка занимает более часа для 3 пользователей)

TestPlan

Результаты Performance Center:

У каждого сэмплера есть менеджер заголовков HTTP

Весь план испытаний

Answer 1

Если вы отправляете одинаковые запросы, у вас должно быть одинаковое время ответа, независимо от того, какой инструмент используется под капотом.

Трудно сказать, в чем различия, не видя полных сценариев от обоих инструментов, поэтому общий совет c заключается в использовании стороннего анализатора, такого как Wireshark или Fiddler , чтобы выявить различия и настроить JMeter так, чтобы он вел себя точно так же, как «центр производительности» (чем бы он ни был)

Например, я не вижу HTTP Cache Manager и его заставит JMeter загружать встроенные ресурсы (изображения, скрипты, стили, звуки, шрифты) для каждого HTTP-запроса, в то время как настоящий браузер делает это только один раз.

Я также не вижу Диспетчер заголовков HTTP , что может быть очень важно, например, если вы отправите заголовок Accept , сервер будет знать, что клиент может понять gzipped ответы, которые значительно уменьшат трафик сети c.

Дополнительная информация: Как заставить JMeter вести себя как настоящий браузер