А зачем переотправлять запросы при 504-й ошибке?

Я за то, чтобы по умолчанию в Thread Group ставить Next Iteration в настройке On Error, вместо Continue.

Тогда скрипты становятся стабильнее

Из минусов, сценарий становится короче. Но ведь это только при ошибках.

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

Как сказал заказчик, в nginx стоит 10 секундный тайм-аут и если ядро в течении 10 секунд не отвечает, то появляются 504 ошибки, а тесты проводить надо

А какие SLA у сервиса?

Это считается багом, что там не отвечает 10 секунд

Тестирование с какой целью проводится, чтобы все респонзы 200 были, или чтобы время ответа померить

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

Если клиенты будут так же получать 504 и так же ломиться дальше, то нормальная цель — посмотреть «как будет в реальности»

Ну значит вы задудосили сервис и хотите узнать что будет если его добивать

По моему субъективному мнению сложная логика в сценариях, это неправильно. Всякие if, while, for проверяют скорее какие-то функциональные требования

Всякие ветвления добавляют проблем только, с логгироанием и анализом

Лучше по моему просто прямые линейные сценарии делать, без опций

Если опции нужны, то это другой уж кейз и нужно ещё один линейный сценарий сделать, который начинается как предыдущий

Циклы вообще бы не использовал

Для повторяющихся действий есть катушки

Пфф

Звучит как «я за всё хорошее против всего плохого»

Как будто народ часто добавляет ветвления от любви к искусству а не по необходимости

Есть такая группа инструментов "бешеный пользователь". Цель таких инструментов -- нагрузить систему, без определенного профиля нагрузки по интенсивности. Но с профилем по количеству. Например, это утилита или скрипт, которая получает на вход число 1000, и должна создать 1000 документов.

Метрика в таком инструменте -- длительность от момента старта, до момента завершения всего теста, среднее время одной операции, если оно фиксируется.

Тут да, стоит добиваться успешной работы.

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

Был пример на stackoverflow от специалиста с индийским именем, он программно дерево элементов создавал на Groovy.

@aklexel помнишь такой код смотрели. Сохранилась ссылка?