Просто оберни все в цикл forever. Но тогда в setUp надо указать максимальную длительность, иначе не остановится:
https://gatling.io/docs/current/general/simulation_setup/#maximum-duration

Заработало, спсасибо!

Теперь все же хочу прояснить, цифры в репорте. Этот график фактически показывает сколько сценариев выполнялось в определенный момент времени, то есть сколько запросов в секунду в определенный момент времени получается? Если да, то понятие пользователей абстрактное, или что такое 1 пользователь НАПРИМЕР  constantConcurrentUsers(1) during(20 seconds) на самом деле для Гатлинга?

Аналог Thread в JMeter. ConcurrentUser ~= поток из пула, который выполняет задачи.

Например, в Джмитер указываешь 5 потоков с 1 реквестом и делаешь паузу 1с => получается ~ 5 запросов в секунду (по 1 от каждого пользователя). Здесь почему-то не так получается

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

В Gatling также

Просто я пробовал constantConcurrentUsers (5) during (10 seconds) без pace(1 seconds)  делать но делал .pause (1 seconds) и не получалось 5 реквестов в секнуду (типа по 1 запросу от каждого юзера в секнуду)

У Gatling есть ловушка в виде его DSL, этот DSL простой и очень гибкий. Часто компилятор не сообщит об ошибке, когда она есть. Сейчас DSL без forever и с ним были корректными по синтаксису, но только с forever был верным.

pause в Gatling просто таймер, как Flow Control Action с паузой на 1 сек в JMeter. Или Constant Timer. Или Random Timer.

А то, что может дать эффект запросов в сек в JMeter - Constant Throughput Timer или Precise Timer. Их аналог в Gatling - pace

Спс плюс минус понимаю. Я просто лоад только пытаюсь делать, потому что в основном е2е тесты писал, поэтому может что-то не понимаю банально простого с лоад тестами .....

Или же я скажу проще. Банально является задача проверить выдержит ли сервер 1000 пользователей. Мы очень приблизительно знаем, что реальный пользователь в среднем более 1 реквеста в секнуд делать не будет (а то меньше), поэтому я поставил себе задачу натравить 1000 пользователей с 1 реквестом в секунду от каждого. То есть данную задачу я так понимаю правльно реализовать, используя pace (1 seconds)  (иначе будет больше запросов)

+ setUp(Notifiaction.inject(rampUsers(1000) during (1 minute)).protocols(httpProtocol)).maxDuration(10 minutes) ?

Тут будет меньшая интенсивность

1000 сценариев за 1 минуту == 1000/60 сценариев в сек. Это 16.67 в сек будет стартовать

Если они будут работать меньше сек, то будете видеть 16-17 активных пользователей в сек. А если они будут работать больше 1 сек, то активных будет больше 17

можно и так сказать, но не совсем верно: в jmeter в одном thread работает один виртуальный юзер, поэтому полуется некоторое тождество данных определений - thread и вирт юзера

Да, слово "Аналог" тут важное

Да, но когда поднимутся все 1000 пользователей, тогда в течение maxDuration (10 minutes)  (т.е. 10 минут) все они 1000 юзеров будут делать по 1 запросу в секнду, все правильно?

Для rampUsers нет момента поднятия. Профиль расчитается до старта теста.

Notifiaction.inject(rampUsers(1000) during (1 minute)

Тут написано, что 1000 пользователей должны запуститься за 60 сек. Gatling будет каждую секунду равномерно стартовать 16-17 новых. Вне зависимости от того, как там они работают. И через минуту перестанет стартовать их.

Если среди запущенных за минуту будут зависшие, то через 10 минут их работа будет прекращена