Size: a a a

QA — Load & Performance

2020 October 19

s

sergeyHa in QA — Load & Performance
Есть вот вариант
https://jmeter-plugins.org/wiki/ArrivalsThreadGroup/
https://jmeter-plugins.org/wiki/ThroughputShapingTimer/

Если нужна супер точность на любых промежутках времени, то вот этот вариант надежен, я по ниму делал
https://www.blazemeter.com/blog/how-to-easily-implement-pacing-jmeter
источник

s

sergeyHa in QA — Load & Performance
источник

s

sergeyHa in QA — Load & Performance
источник

s

sergeyHa in QA — Load & Performance
источник

s

sergeyHa in QA — Load & Performance
источник

s

sergeyHa in QA — Load & Performance
источник

s

sergeyHa in QA — Load & Performance
pacing считается автоматом в excel только интенсивность задаешь и все
источник

ГВ

Григорий Вагайцев... in QA — Load & Performance
С пейсингом вроде ясно,да . А как задавать кол-во юзеров для каждой операции отдельно? Делать несколько тред групп,для каждой операции своя тред группа?
источник

s

sergeyHa in QA — Load & Performance
Григорий Вагайцев
С пейсингом вроде ясно,да . А как задавать кол-во юзеров для каждой операции отдельно? Делать несколько тред групп,для каждой операции своя тред группа?
Да, я так делаю, у меня норм работает
Но конечно может есть вариант лучше и кто то предложит его
источник

ГВ

Григорий Вагайцев... in QA — Load & Performance
Степа Фомичев
Запихивать каждый запрос в test fragment не стоит, наверное, он нужен, если эти фрагменты переиспользуются
Я тест фрагмент использую чтобы можно было сделать две тред группы, одна для дебага,на 1-2 итерации, а вторая тип рабочая. И обе ссылаются на один тест фрагмент. Вот тут подсмотрел https://www.google.com/amp/s/loadtestweb.info/2017/08/18/%25D1%2580%25D0%25B5%25D1%2586%25D0%25B5%25D0%25BF%25D1%2582-%25D1%2585%25D0%25BE%25D1%2580%25D0%25BE%25D1%2588%25D0%25B5%25D0%25B3%25D0%25BE-%25D1%2581%25D0%25BA%25D1%2580%25D0%25B8%25D0%25BF%25D1%2582%25D0%25B0-jmeter/amp/
источник

СФ

Степа Фомичев... in QA — Load & Performance
Да, ок, я просто подумал что вы каждый запрос в тест фрагмент засовываете)
источник

VG

Viktor Ganeles in QA — Load & Performance
Григорий Вагайцев
Всем привет.
Подскажите плз по Jmetr’у
Вопрос такой - как организовать сценарий.
Например, требуется выполнять 1-ю операцию 10 раз в минуту, а 2-ю операцию 3 раза в минуту(условно).
Каждая операция завернута в свой TestFragment(это же ок практика?)
Так вот, как при помощи ultimate thread group подать нагрузку так, чтобы операции выполнились с их требуемыми интенсивностями? На сколько я понимаю, в utg можно нстраивать сценарий только для всей тред группы целиком, без разбивки на операции.
Ну а если короче, как составлять примерно вот такие сценарии(как на скрине) в JMeter, аналогичные HP LR Controller?
варианты следующие:

1) наиболее похожий на LR:
Количество пользователей регулируется через *Ultimate Thread Group*
вместо Pacing в самом начале тредгруппы размещается *Flow Control Action* внутри которого лежит *Constant Throughput Timer*
Меня он радует тем, что я всё сам контролирую и бесит крайне неудобным способом настройки Ultimate Thread Group

2) Более удобный вариант:
Используете обычные тредгруппы, количество потоков проставляете с запасом с самого начала теста.
(работать они будут все)
В самом начале тредгруппы размещается *Flow Control Action* внутри которого лежит *Throughput Shaping Timer*
В нём задаёте RPS (не для каждого VU как в LR, а итоговый, который должен подаваться jmeter-ом)

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

==
источник

VG

Viktor Ganeles in QA — Load & Performance
есть ещё более крутосваренные варианты:
- я использую вариант 1, доработанный до того, что в UserDefinedVariable я пишу процент профиля, а Pacing/Threads расчитываются сами.

- у Кирилла (чуть выше был выложен JMX) вариант 2, но количество тредов тоже само расчитывается под нужный RPS
источник

ГВ

Григорий Вагайцев... in QA — Load & Performance
Viktor Ganeles
варианты следующие:

1) наиболее похожий на LR:
Количество пользователей регулируется через *Ultimate Thread Group*
вместо Pacing в самом начале тредгруппы размещается *Flow Control Action* внутри которого лежит *Constant Throughput Timer*
Меня он радует тем, что я всё сам контролирую и бесит крайне неудобным способом настройки Ultimate Thread Group

2) Более удобный вариант:
Используете обычные тредгруппы, количество потоков проставляете с запасом с самого начала теста.
(работать они будут все)
В самом начале тредгруппы размещается *Flow Control Action* внутри которого лежит *Throughput Shaping Timer*
В нём задаёте RPS (не для каждого VU как в LR, а итоговый, который должен подаваться jmeter-ом)

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

==
по поводу п1.
я верно понимаю, что с помощью *Constant Throughput Timer* мы регулируем рпс(в минуту) для каждого потока(юзера) а в *Ultimate Thread Group* уже задаем собственно кол-во этих потоков(юзеров)?
источник

VG

Viktor Ganeles in QA — Load & Performance
Григорий Вагайцев
по поводу п1.
я верно понимаю, что с помощью *Constant Throughput Timer* мы регулируем рпс(в минуту) для каждого потока(юзера) а в *Ultimate Thread Group* уже задаем собственно кол-во этих потоков(юзеров)?
Ага
Только в этом таймере не rps а rpm
источник

ГВ

Григорий Вагайцев... in QA — Load & Performance
Viktor Ganeles
Ага
Только в этом таймере не rps а rpm
ага, а еще вопрос, рядом лежащие несколько *Ultimate Thread Group*. стартуют +- одновременно?
источник

VG

Viktor Ganeles in QA — Load & Performance
Да
источник

VG

Viktor Ganeles in QA — Load & Performance
Если хотите, что бы они стартовали с задержкой - у них есть параметр _init delay_
источник

ГВ

Григорий Вагайцев... in QA — Load & Performance
Понял, спасибо всем большое за ответы)
источник

VG

Viktor Ganeles in QA — Load & Performance
но блин, тому, кто придумывал интерфейс Ultimate Thread Group с суммирующимися длительностями нужно..
..было подумать об удобстве пользователей
источник