Коллеги, добрый день!
Заказчик хочет управлять RPS и количеством потоков для каждого сервиса. Правильно понимаю, что под каждый запрос нужно будет создать Thread Group, добавить Precise Throughput Timer, вынести их параметры в уникальные переменные? Если запускать какой-либо сервис не требуется, то просто указать ему нулевое количество потоков (проверил - работает), или есть более красивое решение?

Что то не вяжеться, тут либо РПС либо потоки

зачем вместе?

Как выдать 100РПС на 1 потоке если сервис отвечает секунду?)

и обратное, зачем давать 1000 потоков ради 1 РПС

Да, бред выходит. Можно ли как-то завезти выбор - потоки или RPS? Например, выбрал потоки - RPS не можешь задать, хочешь RPS - смотри потоки в результатах работы.

можно, но я бы уточнил цели, возможно заказчик не до конца понимает что хочет

думаю так работать не будет, для корреляции потоков и рпс есть вот такая вещь:
https://www.blazemeter.com/blog/using-jmeters-throughput-shaping-timer-plugin ${__tstFeedback(blazemeter-timer,10,40,10)}

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

Спасибо за ответы. В первую очередь начну с уточнения цели, т.к. при текущих данных известно лишь, что рано или поздно стенду станет плохо от нагрузки.

теоретическое обоснование
https://studfile.net/preview/2419983/page:6/
https://en.wikipedia.org/wiki/Little%27s_law

Хм... Возникает такой вопрос: если заказчик не знает, что он хочет, то как помочь ему захотеть что-то конкретное? Думаю, нужно начать с поиска максимума системы.

почему бред? может быть вполне обосновано. К примеру, пользователи подолгу висят на сервере и это оказывает свой эффект. Или может быть 5000  пользователей создают  на проде интенсивность запросов, к примеру, 100 рпс и  нужно проверить вывезет ли сервис 10k активных подключений и интенсивность запросов в рамках 200рпс

В нашем случае тестируется нагрузка шины (SOAP, MQ запросы), потому висящих пользаков не будет. Если заказчик придёт к мысли, что нужно чётко знать пропускную способность шины, то остановимся, скорее всего, именно на RPS.

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

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

ну это такое себе

есть вариант с обычной тред-группой

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

Но в итоге приличное время уходило на "устаканивание" потоков и пэсингов:
- Запуск теста, что-то-там расчиталось, полетели запросы
- Shaping timer увидел, что времена отклика большие, производительности не хватает, заюзал все потоки
- Concurrency Thread Group накидал ещё потоков
- производительность скачком увеличилась
- Shaping timer увидел, что перегружает, увеличил pacing
- сократилось количество заюзанных потоков, нагрузка резко упала

и такие качели длились несколько минут.
А у нас обычные тесты - ступеньчатые, нам эти качели на каждой ступеньке не нужны.
Нам проще один раз вставить jsr223, который посчитает pacing и потоки для всего теста а потом будет их придерживаться.
Один минус - если времена отклика станут слишком большими, нагрузка станет меньше требуемой. Но значительный рост времени отклика - это уже причина считать, что максперф найден и останавливать тест.

PS Может в тесте с высокими интенсивностями и мелкими временами отклика всё было бы замечательно.