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

Вячеслав про то что надо не забыть повторить логику веб приложения в разрезе обработки ошибок. Ну я так понял

@login40k в нагрузочном скрипте JMeter хотя бы поменять логику работы Thread Group с Continue on error, на Next iteration. Уже будет ближе к оригиналу.

А вопрос очень хороший.
Попробовал использовать переменную ${JMeterThread.last_sample_ok} - она не заполняется в JMeter для транзакций без опции Generate Parent Sampler.

Использовал выражение в If Controller:

${__jexl3(${JMeterThread.last_sample_ok}==false)}

Если в Transaction Controller не стоит Generate Parent Sampler, то на втором рисунке видно, что Transaction Controller неуспешный, но условие не срабатывает. Третий успешный запрос меняет статус переменной на true, а Transaction Controller ничего не меняет.

Если же в Transaction Controller стоит Generate Parent Sampler, то условие срабатывает. И после If Controller итерация прерывается, запрос Java Request Final не выполняется. Что видно на рисунке 3.

Таким образом, если нужно реагировать на суммарный результат выполнения группы запросов. Придется использовать Transaction Controller с опцией Generate Parent Sampler

День добрый.
Не в первый раз наблюдаю за гатлингом некоторую "особенность":
Когда во время теста сервис нагрузку выдерживает - показатель RPC растет вместе с количеством сгенерированных пользователей. Собственно все, как и задумывалось.

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

Никто не вкурсе, может у него есть какой-то ключик, типа "safe mode", который может это отключить?

так проблемы же с сервером а не с гатлингом, разве нет?

Ну с сервером определенно есть проблемы - он с нагрузкой перестает справляться.
Но гатлинг то чего не сыпет запросами? Я генерирую ему 1000 пользователей, которые вчера успешно делали нагрузку в 1000 rps.

А сегодня тот же самый сценарий , при тех же 1000 пользователей показывает на всех графиках всего 300 rps.

И в итоге ко мне вопросы, что я тестирую не тот уровень нагрузки, который указан в требованиях, а намного меньший ))

вроде все верно 1000 пользователей могут генерить нагрузку в 1000 рпс при условии, что время ответа не больше 1 секунды. При увеличении времени ответа количество рпс на теже 1000 пользователей падает Threads pool size can be calculated like RPS * <max response time> / 1000

Тут помогает throttling. Используйте его

В дополнение к текущему профилю

покажи как пуляешь нагрузку

Тротлинг пробывал - у него есть один неприятный сайд эфект - все пользователи, которые не проходят через заслонку остаются в очереди. И со временем их там становится сильно много, в результате чего вылетаеют ошибки перполнения java heep или outOfMemory

а какое ожидаемое поведение?

если у тебя сервер не отвечает, либо они будут копиться либо их будет меньше

Пуляю нагрузку так (тут не весь код, но вродь все, что по смыслу подходит):
https://gist.github.com/Sugrob57/b7cacd5c8e9cc5846bb276e80fb80bde

pace(1 seconds)

ну вот всё что респонстайм > 1 секунды, то нагрузка расти не будет

Ожидалось что нагрузка будет рости вместе с юзерами.
И это работает когда серверу хорошо.

Но когда разработчики что-то не то накатят и все начинает тормозить - я и нагрузку дать не могу из-за долгих ответов)