Измените количество потоков плана тестирования в JMeter во время выполнения

IMHO это просто причудливая функция, которая не имеет реальной выгоды при проведении надлежащего тестирования производительности. Чтобы сгенерировать соответствующий тестовый вывод (отчет), вам нужно пов, и ясно определенные методология и сценарии теста. Для сравнения влияния любых изменений приложения/сервера/инфраструктуры необходима повторяемость.

Что значит

мы не можем предсказать пользователей нашего сайта

вот почему мы делаем тестирование производительности в первую очередь. Чтобы узнать, что такое наш предел приложения/инфраструктуры.
Т. е. наиболее важным показателем, который можно создать, является изменение времени отклика приложения при изменении числа параллельных пользователей. Но не изменяться беспорядочно, во время выполнения.

с конечная группа потоков плагинов JMeter вы можете охватить любой мыслимый сценарий.

эта функция действительно полезна, и удивительно трудно реализовать даже с коммерческими инструментами, такими как Loadrunner. Я бы сравнил это с поиском максимальной громкости громкоговорителей. Вы вручную увеличите громкость до тех пор, пока она не начнет потрескивать, а затем немного уменьшите ее, чтобы поддерживать максимальную громкость. Точно так же, чтобы найти пиковую емкость приложения, вы хотите, чтобы control "увеличил громкость" до тех пор, пока не будут замечены ошибки, а затем немного уменьшил ее, чтобы увидеть, стабилизируется ли она. Затем вы можете поддерживать эту нагрузку, чтобы найти, где находится узкое место.

в любом случае, чтобы ответить на вопрос, что я сделал в прошлом, это использовать внешнее влияние, такое как имя файла или подобное. Затем объедините это с уникальной ссылкой потока, которую вы можете контролировать, какие потоки выполняются и которые удерживаются (путем паузы или аналогично).

например, если вы начинаете с 100 потоков, то создайте файл с именем '5.txt' в определенном месте, вы можете добавить код такой, что если потоки видит, что его собственная ссылка равна или ниже, чем число, которое он может запустить. Если нет, то он падает в паузу. В начале этого примера будут выполняться 5 потоков, а 95-пауза. Затем вы можете переименовать файл в '25.txt', и потоки от 6 до 25 начнут работать. Это сработало бы и в другую сторону, изменив его на '20.txt ' будет означать, что потоки 21-25 снова пауза.

ключ должен начать достаточно потоков, чтобы превысить ожидаемый пик.

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

в Jmeter как установить переменное количество потоков, используя переменную BeanShell sampler?

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

• тест продолжительности-такое же количество потребителей бежит все время (по возможности с коротким периодом нарастания)
• тест точки прерывания-пандус вверх по количеству потребителей инкрементально до перерывы приложений
• Spike test-запуск с постоянным количеством пользователей, но спорадически
  бросать в большое количество пользователей

тест точки останова пандусы вверх по количеству потребителей пока приложение не сломается (дело в том, чтобы увидеть, насколько высоко ваше приложение может масштабироваться). Вы можете сделать это, используя свойство группы потоков "увеличить период". Если вы установите время нарастания до 1000 и количество потоков до 100, он будет добавлять 1 поток каждые 10 секунд.

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

Я нахожу, что Jmeter не обрабатывает все сценарии нагрузочных испытаний, которые необходимы в корпоративном нагрузочном тестировании. Одна из работ вокруг Im-это просто запустить все потоки, но найти способ заставить некоторые из них спать. Так что вы можете установить количество потоков до 1000, но как-то 980 из них спать или ничего не делать. Затем, возможно, когда time_in_seconds%5==0 (каждые 5 минут) вы позволяете другим потокам запускать - имитируя тест Спайка. Идея вы можете жестко закодировать потоки до 1000 и всегда будете иметь 1000 потоков, но они не должны все время что-то делать.

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

обновление: Я только что нашел этот плагин, который позволяет различные типы тестирования. Еще не пробовал, но выглядит многообещающе: http://jmeter-plugins.org/wiki/ThroughputShapingTimer/

вы можете установить/изменить количество потоков во время выполнения с помощью опции командной строки...

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

Предположим, вы хотите иметь возможность изменять число нитей в плане тестирования. Выберите подходящее название свойства, скажем group1.нити. Заменить счетчик потоков в GUI (или JMX, если вы чувствуете себя храбрым!) со следующим вызовом функции:

пожалуйста, установите ниже свойство в группе резьбы JMeter, как показано ниже ${__property(group1.threads)}

затем, при запуске JMeter, определите свойство в командной строке:

в JMeter -Jgroup1.threads=10

мы не можем предсказать пользователем нашего сайта.

конечно, вы можете. Это то, для чего предназначены журналы HTTP вашего существующего сайта. Вы также можете использовать журналы из таких инструментов, как Omniture или журналы CDN. Если вы посмотрите на комбинацию фактического IP-адреса пользователя, запроса и тегов referer в журналах, вы сможете создать карту обхода одного пользователя на своем сайте. Вы сможете профилировать страницы уникального листового узла high hit данного бизнес-процесса, чтобы понять, сколько раз конкретный бизнес-процесс происходит в часе. Вы сможете изучить оставление, взглянув на воронку в таких инструментах, как Omniture. Если вам нужны инструменты для этого анализа, я рекомендую чмок. Его легко установить и настроить. Окупаемость очень быстрая.

чем больше данных журнала у вас есть, которые вы используете для профиля, тем ближе вы можете прийти к фактическому для того, что пользователи делают в течение дня/недели/месяца/спот-продажи/конец квартала/конец года/и т. д....Тебе нужно чтобы объединить фактическое в данный момент времени с фактическим из более ранних точек времени для проецирования роста с течением времени, так как вам нужно будет учитывать рост в вашей модели тестирования производительности.

Если вы не получите значения правильно, то значение вашего теста как предиктора того, что будет/может произойти в производстве, будет довольно низким. Это не сбой какого-либо инструмента, а сбой в процессе планирования модели фактической нагрузки, используемой в рамках требований к испытаниям. Если вы не можете постройте эти модели, тогда вам нужно вытащить кого-то в свою команду, кто может.

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

включение сервер BeanShell вы можете изменять свойства во время выполнения. Просто включите его и telnet на порту 9001 (предупреждение: не безопасно!) Основываясь на тесте, который я сделал, unfortnately, кажется, что количество потоков не применяется во время выполнения. Однако вы все равно можете манипулировать нагрузкой теста другими средствами, например, применить таймер пропускной способности costant параметризован свойством с именем "пропускная способность" и изменяет его во время выполнения, как это:

setprop("throughput","2000");

это хорошо объяснено в руководстве.