Почему разница при использовании Jmeter для загрузки теста против HP Load runner?

Question

Вот сценарий

Мы загружаем тестирование веб-приложения.Приложение развернуто на двух виртуальных серверах с аппаратным балансировщиком нагрузки, распределяющим нагрузку.

Здесь используются буксирные инструменты 1. HP Load Runner (дорогой инструмент).2. JMeter - бесплатно

JMeter использовался командой разработчиков для тестирования огромного количества пользователей.Он также не имеет никаких ограничений лицензирования, как Load Runner.

Как выполняются тесты?URL-адрес вызывается с некоторыми параметрами, и веб-приложение считывает этот параметр, обрабатывает результаты и генерирует файл PDF.

При запуске теста мы обнаружили, что при загрузке 1000 пользователей в течение 60 секунд наше приложениепотребовалось 4 минуты, чтобы сгенерировать 1000 файлов.Теперь, когда мы передаем один и тот же URL через JMeter, 1000 пользователей со временем разгона 60 секунд, приложению требуется 1 минута и 15 секунд, чтобы сгенерировать 1000 файлов.

Я озадачен тем, почему эта огромная разница впроизводительность.

На загрузчике установлен демон rstat на обоих серверах.

Есть какие-нибудь подсказки?

Answer 1

У вас действительно есть четыре возможности:

1. Вы измеряете две разные вещи. Проверьте свою структуру записи времени.
2. Информация о вашем запросе и ответе различна для двух инструментов. Проверьте с Fiddler или Wireshark.
3. Начальные условия вашей тестовой среды отличаются, что приводит к разным результатам. Протестируйте 101 материал, но довольно часто упускается из виду при отслеживании подобных проблем.
4. В вашей среде loadrunner имеется перегруженный генератор нагрузки, который замедляет работу всех виртуальных пользователей. Например, вы можете регистрировать все, что приводит к тому, что ваша файловая система становится узким местом для теста. Умышленно недооценивайте свои генераторы, уменьшайте уровни ведения журналов и следите за тем, как вы используете память для корреляций, чтобы не создавать условия переподписки физической памяти, что приводит к высокой активности подкачки.

Что касается приведенного выше комментария о том, что JMETER работает быстрее, я провел сравнительный анализ и для очень сложного кода, решение на основе C для Loadrunner быстрее при выполнении от итерации к итерации, чем решение на основе Java в JMETER. (метод: сложный алгоритм создания файлов данных на лету для загрузки для пакетной обработки ипотеки. p3: 800 МГц. 2 ГБ ОЗУ. LoadRunner 1,8 млн. итераций в час для одного пользователя. JMETER, 1,2 млн.) время отклика сервера, определяемое для обоих.

Следует отметить, что LoadRunner отслеживает свое внутреннее время API, чтобы напрямую реагировать на обвинения в использовании инструмента, влияющего на результаты теста. Если вы откроете набор базы данных набора результатов (.mdb или экземпляр сервера Microsoft SQL в зависимости от ситуации) и взгляните на таблицу [счетчик событий], вы найдете ссылку «Потраченное время». Определение потерянного времени можно найти в документации LoadRunner.

Answer 2

Скорее всего, виновник в том, КАК структурированы скрипты.

Что нужно учитывать:

• Время обдумывания / ожидания: при записи Jmeter не вставляется автоматически ждет.
• Запрашиваемые товары: Есть Jmeter ТОЛЬКО запрос / загрузка HTML-страницы, в то время как Load runner получает все встроенные файлы?
• Неправильные ответы: все ответы 1000 Jmeter действительны? Если у вас есть 1000 потоков из один рабочий стол, я бы заподозрил тебя убил Jmeter и не все твои ответы были действительными.

Answer 3

Не забывайте, что тестовое приложение само измеряет себя, так как получение ответа зависит от времени машины тестирования. Таким образом, с этой точки зрения это может быть ответом, что JMeter просто быстрее.

Второе, что следует упомянуть, это время ожидания, упомянутое BlackGaff.

Всегда проверяйте результаты с помощью дерева результатов в jmeter.

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