Какое наибольшее количество потоков целесообразно одновременно запускать в Jmeter?

JMeter может имитировать очень высокую нагрузку при условии, что вы используете его правильно.

Не слушай Городские Легенды это говорит, что JMeter не может обрабатывать высокую нагрузку.

теперь что касается ответа, это зависит от:

• мощность вашей машины

• ваш jvm 32 бит или 64 бит

• ваша выделенная память jvm-Xmx

• ваш план тестирования ( много beanshell, почтовый процессор, xpath ... Означает много cpu)

• конфигурация вашей ОС (настраиваемая)

• режим Gui / non gui

Так нет теоретических ответов, но после Лучшие Практики обеспечит JMeter выполняет хорошо.

заметьте что с jmeter вы можете распределить нагрузку через дистанционное испытание, прочитайте:

• дистанционное тестирование > 15.4 с использованием другого образца отправитель

и, наконец, использовать облачное тестирование, если этого недостаточно.

прочитайте это для советов по настройке:

• http://www.ubik-ingenierie.com/blog/jmeter_performance_tuning_tips/

Вики JMeter сообщает случаи, когда JMeter использовался с целых 1000 потоков. Я использовал его не более чем с 100 потоками, но ссылки в Wiki предполагают сокращение ресурсов, которые я никогда не пробовал.

одной из проблем, с которой мы столкнулись при запуске JMeter в Windows XP, был предел TCP-соединения Windows XP. Предел должен быть удален, чтобы запустить использование JMeter для полного потенциала рабочей станции Подробнее здесь. AFAIK, не применяется к другим ОС.

Я использовал JMeter с 2004 года, и я запустил много нагрузочных тестов.

с ПК Windows 7 64 бит 4GO RAM iCore5.

Я думаю, что JMeter может поддерживать от 300 до 400 параллельные потоки для протокола Http (Sampler) только с одним "Aggregate Report Listener", который записывает в файл журнала результаты и таймеры между страницами звонок.

для большого нагрузочного теста вы можете настроить JMeter с рабами (генераторами нагрузки), такими как этот http://jmeter-plugins.org/wiki/HttpSimpleTableServer/

Я уже сделал тесты с 11 рабами ПК для имитации 5000 потоков.

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

Источник Википедия.

число угадайку...

эта довольно простая игра начинается примерно так: "я думаю о целочисленном числе от сорока до шестидесяти включительно, и на ваши догадки я отвечу "высокий", "низкий" или " Да!- возможно, так оно и есть." Предположим, что N-это число возможных значений (здесь было указано двадцать одно как "включительно"), тогда для определения числа требуется не более вопросов, так как каждый вопрос вдвое уменьшает пространство поиска. Обратите внимание, что один вопрос (итерация) требуется меньше, чем для общего алгоритма, поскольку число уже ограничено определенным диапазоном.

даже если число, которое мы предполагаем, может быть сколь угодно большим, в этом случае нет верхней границы N, мы все равно можем найти число в большинстве шагов (где k - (неизвестное) выбранное число), сначала найдя верхнюю границу путем повторного удвоения. Например, если число будет 11, мы можем использовать следующую последовательность попыток найти его: 1, 2, 4, 8, 16, 12, 10, 11

также можно было бы распространить методика включения отрицательных чисел; например, следующие предположения может быть использована для поиска -13: 0, -1, -2, -4, -8, -16, -12, -14, -13

Это больше зависит от вида тестирования производительности, которое вы делаете (загрузка, всплеск, выносливость и т. д.) На определенном сервере (немного на аппаратной зависимости)

имейте в виду эти параметры - клиентская машина, на которой вы ориентируетесь на запуск jmeter, будет выделено определенное количество памяти кучи, убедитесь, что у вас есть здоровое распределение, чтобы сценарий не ошибался. Самый высокий, который я запускал на jmeter, был 1500 в локальной среде ( арка клиент-сервер), На веб-арке самое высокое, что у меня было, было основано на нефункциональном требовании, ограниченном 250 потоками,

таким образом, это идеально зависит от видов тестирования производительности и стиля развертывания и так далее..

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

чтобы узнать максимальные потоки, которые может обрабатывать ваш компьютер, вы можете подготовить образец теста и запустить его только с несколькими потоками. Затем с каждым циклом выполнения теста постепенно увеличивайте количество потоков. Во время этого Вам также нужно контролировать CPU, RAM, дисковый ввод-вывод и сетевой ввод-вывод вашего компьютера. В тот момент, когда любой из них достигнет 80% или более (Снова для вас, чтобы решить, подходит ли near для вас или за его пределами), это максимальное количество потоков, которые может обрабатывать ваш компьютер. Чтобы быть в безопасности, я бы остановился на числе, когда использование ресурсов достигает 70%.

Это будет зависеть от оборудования, на котором вы работаете, а также от базового сценария. Я всегда чувствовал, что эта нечеткость является самой большой проблемой, с традиционными инструментами нагрузочного тестирования. Если у вас небольшой бюджет ($200 или около того дает вам много тестирования), Проверьте мою компанию служба нагрузочного тестирования, BrowserMob.

кроме наших реальных пользователей браузера (RBUs), которые контролируют тысячи на реальных браузерах с целью тестирования производительности и нагрузки, у нас также есть традиционные виртуальные пользователи (VUs). Скрипты написаны на JavaScript и могут совершать различные HTTP-вызовы.

причина, по которой я поднимаю это, заключается в том, что я всегда чувствовал, что игра в попытке выяснить, сколько VUs вы можете поместиться на вашем оборудовании load gen опасна. Так легко получить плохие результаты, не осознавая этого.

чтобы решить эту проблему для BrowserMob, мы приняли чрезвычайно консервативный подход к количеству VUs и RBUs на ядро процессора: не более 1 браузера или 50 потоков на ядро процессора, и иногда гораздо меньше. В мире облачных вычислений циклы процессора настолько дешевы, что просто нет смысла пытаться перегрузить машины.