Каким оразом все это будет происходить.

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

Сценарий состоит из трёх операций пусть. И из 55 запросов. Важно сделать сценарий без if, while, case, ...

Тогда всегда будет 55 запросов в случае успеха (200). И дальше контролировать остаётся только сценарии.

Делаю так.

Технически делаю чаще всего так. В JMeter есть Test Action (пауза на 0 сек) и таймер к ней - Constant Throughput timer.

Отличие JMeter от Gatling тут в наличии фиксированного пула потоков в JMeter.

Если тест на поиск максимума, то это важно.

При повышении нагрузки система начинает отвечать медленнее, тут gatling начинает добавлять пользователей, а JMeter просто не может этого делать. У него пользователей столько, сколько в пуле задано. И у gatling нагрузка не просядает, но он может упасть в out of memory, а JMeter не падает (если настроен) но у него нагрузка просядает.

В gating тоже можно ограничить количество потоков, например  используя constantConcurrentUsers

@smirnovqa если в курсе, есть ли софтовое ограничение на на виртуальных пользователей в JMeter? Видел где то статейку, i5+8gb дали примерно 9000 авктивных. Но я хочу запускать через агенты тимсити, там то железяки помощнее. Максимум во что могу упереться это количество активных подключений сети. Так вот и интересно на сколько я смогу разогнать один воркер?

Если сценарий написан с множеством if, while, ... То контролем интенсивности сценария не обойтись. Тут есть другие таймеры. Которые контролируют RPS.

Например.
Throughput Shaping Timer

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

30 запросов в сек, 100 запросов в сек, можно. 0,4 - нельзя

Спасибо.
Я правильно понимаю, что если мы пытаемся достичь РПС в сценарном методе -
То у нас не всегда будет один и тот же запрос в секунду в нужном кол-ве, если после первого запроса нужно из него что-то выдернуть и потом отрпавить второй?

Нет. Если всегда из первого выжигается второй. Или с вероятностью 50. То все будет стабильно.

Сервер будет медленее отвечать, и по этому у нас второй запрос может не совсем попасть в данный рпс

Тогда Throughput Shaping Timer задействует ещё пользователя из пула. Но когда пул закончится, тогда всё. Просядает нагрузка

Можно поставить достаточно большой pacing и закинуть достаточно тестовых данных, то можно получить требуемое количество rps независимо от времени ответа сервиса. Если я правильно понял проблему

Например, в сценарии 10 запросов, таймаут по каждому 60с, ставим pacing 600с. И теперь можно контролировать число rps количеством запуска сценариев в секунду. Только тогда надо очень много тестовых данных)

Все верно. Просто мне стало интересно для чего прописывают RPS  в сценарном методе.
Ведь не всегда следующий запрос может полететь из-за того что серверер притормозил.
Ну и как быть с паузами на ввод данных, мы же тоже это должны учитывать, вот по этому меня и заинтересовало что такое рпс в сценарном методе?

А рпс , если я все верно понимаю - это количество запросов в секунлу?

Не пробовал ещё так совмещать с тротлингом. На сколько помню не получится совместить

Скорее всего не получится.  Это для закрытой модели с pacing

Cпасибо, @smirnovqa ,@jigarkhwar , @chepk  за ответы.
Постараюсь более точнее задать вопрос.
А точнее описать кейс.
И точнее описать логику рпс как я ее вижу

Есть как минимум 2 вида rps: 'количество сценариев в секунду' и 'количество выполнений какого-нибудь шага в секунду'

Если сценарий это покупка в магазине, то может оказаться 100 покупок в час, и при этом 500 действий 'положить в корзину' в час. Вот вам и rps