Время выборки (мс) отличается от времени ответа Loadrunner для одного и того же запроса. Почему это так?

Question

Мы записали запрос на запуск страницы веб-сайта в Jmeter, исключая все файлы статического содержимого css, js и т. Д. Когда мы воспроизводили сценарий, время выборки (учитывая, что это время ответа) приближалось к 5000 мс.

Мы записали тот же запрос в LoadRunner, и время ответа составляло около 300 мс. Также, когда мы увидели время ответа на запрос через HTTPFox, оно также составило около 300 мс.

Мой вопрос заключается в том, почему существует резкое различие между временем отклика, измеряемым двумя инструментами. Я ошибаюсь при расчете времени отклика в Jmeter ИЛИ есть ли другой способ рассчитать время отклика в Jmeter?

Answer 1

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

У вас также есть тестовые элементы конфигурации, которые могут вступить в игру, например, JMETER, выполняющий монолитный на одном хосте, против loadrunner, работающий на множестве генераторов. Подумайте, время установки различий, количество пользователей. и т. д. Вы могли бы потратить весь день на гвозди тестовых настроек и архитектуры.

Но, учитывая, что время Loadrunner ближе всего к наблюдаемому при использовании прокси и ручного выполнения, что вы можете сделать из остальных тестовых данных?

Answer 2

Я вижу несколько причин того, почему это может произойти:

1. JMeter настроен на "Перенаправлять автоматически" или "Следовать за перенаправлениями"
2. JMeter настроен для "загрузки встроенных ресурсов"
3. Тестируемая система демонстрирует высокую задержку (количество времени, в течение которого запрос достигает сервера, JMeter сообщает об общем времени отклика в виде задержки + фактического времени отклика, объяснение метрик см. В Руководстве по загрузке отчетов)