KY
и так и так вроде можно
тогда как будут достигаться эти интенсивности если выполнение внутри сценария будет последовательным
Size: a a a
2019 January 09
C
несколько сценариев находятся в одной тред группе, трупат таймер выставляется сразу для всей группы насколько я понимаю а не для сценария
Куда ты его по иерархии дерева запихаешь и какие настройки выберешь - он так и действует
KY
если покажешь буду очень благодерен!
C
тогда как будут достигаться эти интенсивности если выполнение внутри сценария будет последовательным
У тебя есть 10 шагов сценария. Пусть на первом висит 1 рпс на втором 2... И так до 10. Если ты добавляешь 5 таких пользователей, то вместе они будут долбить от 5 rps по первому сценарию до 50 по последнему.
C
если покажешь буду очень благодерен!
Увы, под рукой только мобила.
KY
У тебя есть 10 шагов сценария. Пусть на первом висит 1 рпс на втором 2... И так до 10. Если ты добавляешь 5 таких пользователей, то вместе они будут долбить от 5 rps по первому сценарию до 50 по последнему.
у меня 5 сценариев
KY
с 10 шагами внутри
KY
куда необходимо сунуть констант таймер чтобы верхний каждый из них сделал столько сколько нужно (к примеру: 3 в минуту, 6 в мин, 2 в мин и 4 в мин для каждого соответсветсвенно) за одну минуту
ЕЕ
Поробуй в тест фрагмент, и ты всегда можешь тренироватся на Dummy Sampler
ВС
Товарищи, интересно ваше виденье реализации такой задачки в JMeter.
Есть не сильно сложные сценарии пользователей на сайтике, которые бегают там по HTTPS.
Каждый сценарий пользовательский рождает в итоге какой- то артефакт, есть интенсивность появления этих артефактов в системе, там полный фарш и загрузка больших файлов, и заполнение диких форм с всеможножными куками, и почтовые месаги путем веб-морды и тд. Суть в том, что по какой-то невнятной причине заказчику нужны реальные коннекты, в которых работают юзеры. То есть обойтись просто каким-то количеством юзеров которые бы гоняли нужные интенсивности не выйдет, есть корреляция в этом нет проблемы, но есть проблема в ресурсах. Коннектов для определенной интенсивности требуется, скажем, 2к. При поиске максимума коннекты растут пропорционально интенсивности.
На скорую руку было сделано так: общая катушка тред группы пораждает параллел контроллер, в дочерних элементах, которого транзакции с тупым рандом таймером, который имеет достаточный разброс, чтобы при экраполяции на большие значения превращался в плюс минус верную интенсивность на нужном количестве пользователей.
Хочется: получать интенсивность адекватно путем throughput'ов каких-либо, но в любом случае нечто более точное чем рандом таймер, ну и всё таки работа параллела оставляет желать лучшего, но как под одну катушку сунуть разные сценарии под разной интенсивностью не очень могу себе представить).
Есть не сильно сложные сценарии пользователей на сайтике, которые бегают там по HTTPS.
Каждый сценарий пользовательский рождает в итоге какой- то артефакт, есть интенсивность появления этих артефактов в системе, там полный фарш и загрузка больших файлов, и заполнение диких форм с всеможножными куками, и почтовые месаги путем веб-морды и тд. Суть в том, что по какой-то невнятной причине заказчику нужны реальные коннекты, в которых работают юзеры. То есть обойтись просто каким-то количеством юзеров которые бы гоняли нужные интенсивности не выйдет, есть корреляция в этом нет проблемы, но есть проблема в ресурсах. Коннектов для определенной интенсивности требуется, скажем, 2к. При поиске максимума коннекты растут пропорционально интенсивности.
На скорую руку было сделано так: общая катушка тред группы пораждает параллел контроллер, в дочерних элементах, которого транзакции с тупым рандом таймером, который имеет достаточный разброс, чтобы при экраполяции на большие значения превращался в плюс минус верную интенсивность на нужном количестве пользователей.
Хочется: получать интенсивность адекватно путем throughput'ов каких-либо, но в любом случае нечто более точное чем рандом таймер, ну и всё таки работа параллела оставляет желать лучшего, но как под одну катушку сунуть разные сценарии под разной интенсивностью не очень могу себе представить).
Привет. Верно пишешь. В таком случае нужна одна большая катушка, в которой будут для отдельных операций блоки:
https://jmeter.apache.org/usermanual/component_reference.html#Throughput_Controller
Логика расчета профиля такая:
Реальный пользователь входит
С вероятностью 0.3 он отправляет письмо
С вероятностью 0.4 загружает файл
...
Выходит
Таких пользователей 2000
Jmeter вытянет 2000 тредов
https://jmeter.apache.org/usermanual/component_reference.html#Throughput_Controller
Логика расчета профиля такая:
Реальный пользователь входит
С вероятностью 0.3 он отправляет письмо
С вероятностью 0.4 загружает файл
...
Выходит
Таких пользователей 2000
Jmeter вытянет 2000 тредов
ВС
На весь сценарий будет общий pacing. Пусть хоть 10 минут на пользователя. Но будут честные 2000 тредов
KY
сейчас подумаю! спасибо)
KY
Поробуй в тест фрагмент, и ты всегда можешь тренироватся на Dummy Sampler
на них и делал, пока ничего хорошего
ВС
сейчас подумаю! спасибо)
А схема расчета вероятностей для Throughput_Controller:
- определить самую частую операцию (Вход, обычно)
- для остальных операций посчитать пропорции (0.3, 0.4, ...) относительно главной операции
- определить самую частую операцию (Вход, обычно)
- для остальных операций посчитать пропорции (0.3, 0.4, ...) относительно главной операции
KY
гениально, это ифами ставить?
LY
Месье знает толк )
ВС
гениально, это ифами ставить?
ВС
Месье знает толк )
Ага. Есть заказчики, которым нужны "реальные пользователи".
И простой способ их эмуляции уже придуман.
Да, это дороже по ресурсам. Шаги нагрузки большие. Потоков немало
И простой способ их эмуляции уже придуман.
Да, это дороже по ресурсам. Шаги нагрузки большие. Потоков немало
C
куда необходимо сунуть констант таймер чтобы верхний каждый из них сделал столько сколько нужно (к примеру: 3 в минуту, 6 в мин, 2 в мин и 4 в мин для каждого соответсветсвенно) за одну минуту
С дамми сэмплером у меня чет сходу тоже не получилось, сейчас потыкал немного. На реальных запросах таймер тоже не применяется?