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

Я изрядно использовал JMeter и обнаружил, что он не очень хорош для создания действительно высокой нагрузки. На Core2 Duo с частотой 2 ГГц и 2 ГБ памяти можно разумно ожидать около 100 потоков.

При этом лучше всего запускать его на своем оборудовании, чтобы ЦП ПК не работал на 100% - лучше стабильные 80% -90%, иначе это повлияет на результаты.

Я также пробовал WAPT 5 - он успешно запускал более 1000 потоков с того же ПК. Он не бесплатный, но более удобен, чем JMeter, но не имеет всех функций.

Устаревший ответ по крайней мере с версии 2.6 см. https://stackoverflow.com/a/11922239/460802 для получения дополнительной информации до свидание с одним.

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

Не слушайте Городские легенды, в которых говорится, что JMeter не справляется с высокой нагрузкой.

Что касается ответа, это зависит от:

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

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

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

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

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

• Графический / не графический режим

Итак, теоретического ответа нет, но следование передовым методам обеспечит хорошую работу JMeter.

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

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

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

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

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

Прочтите эту книгу для выполнения нагрузочного тестирования и правильного использования JMeter.

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

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

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

На ПК с Windows 7 64-битная ОЗУ 4Go iCore5.

Я думаю, что JMeter может поддерживать от 300 до 400 одновременных потоков для протокола Http (Sampler) только с одним «прослушивателем агрегированных отчетов», который записывает в файл журнала результаты и таймеры между страницами вызовов. .

Для теста большой нагрузки вы можете сконфигурировать 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 потоками,

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

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

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

Это будет зависеть от оборудования, на котором вы работаете, а также от базового сценария. Мне всегда казалось, что эта нечеткость - самая большая проблема традиционных инструментов нагрузочного тестирования. Если у вас небольшой бюджет (около 200 долларов дает вам БОЛЬШОЕ тестирование), воспользуйтесь услугой нагрузочного тестирования, BrowserMob.

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

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

Чтобы решить эту проблему для BrowserMob, мы использовали чрезвычайно консервативный подход к количеству VU и RBU на ядро ​​ЦП: не более 1 браузера или 50 потоков на ядро ​​ЦП, а иногда и намного меньше. В мире облачных вычислений циклы ЦП настолько дешевы, что просто не имеет смысла пытаться перегружать машины.