Если для них задана известная интенсивность. Пусть 7 итераций в сек, и известно, что они выполняются не дольше 30 секунд. То можно добавить таймер, который выровняет нагрузку.

За минуту выполнится 2 сценария одним потоком. А надо чтобы в минуту было 60*7=420 в минуту. Значит надо не 1 поток, а 210 потоков. Которые будут выполнять сценарии вечно (есть такая галочка).

Далее в начало сценария нужно добавить Flow Control Action. В него добавить Constant Throughput Timer. А в таймере написать - 2.0 (интенсивность: 2 в минуту).

Потом поправить настройки Thread Group:
Количество потоков: 210
Длительность RumpUp - пусть 60 секунд.
Количество итераций - бесконечное.

Same user on each iteration - [v]
Задать длительность теста - пусть также 3030 (чуть меньше часа)

кстати, вы можете при помощи jvisualVM или другим профайлером подключиться к потоку и посмотреть, что он делает.
Попытаться.
(Я так не делал ни разу)

вообще, если поток в состоянии established, значит в нём что-то бегает.
Это может быть keep alive, который поддерживает поток в живом состоянии, а может быть сервер решил не отвечать на ваш запрос (например, у сервера завис поток, который принял коннект и ответа он не высылает.

Вы можете то же самое сделать через http вместо https ?
тогда можно будет с помощью wireshark захватить трафик и посмотреть, есть ли там обмен данными.

убрал галочку keep-alive буду проверять

обрубил этот запрос вручную. Если бы сервер решил не отвечать на этот запрос, у сервера завис поток, то он должен был принят коннект, верно ли я понимаю, что если бы он принял коннект, то значение Connect у этого запроса не было бы 0 ?
Вот строка этого запроса

А что такое "значение Connect"?

в скринах нетстата есть:
- Протокол (TCP)
- ip:port источника, то есть твоего жметра  (192.168.0.107:53701)
- ip:port назначения, то есть объекта тестирования  (52.166.141.32:https)
- состояние (ESTABLISHED, то есть активно)
- PID процесса, который работает с коннектом (9336, выводится если есть ключик -o)

Аа. я понял тебя

не знаю ответа.

состояние (ESTABLISHED, то есть активно) - а это значит, что соединение с объектом тестирования всё таки было установлено ?)

Не просто установлено, но и поддерживается.

Если в tcp-соединении завершился обмен данными, высылается пакет “fin”, типа «можно закрывать»

Но коннект ещё некоторое время живет в состоянии time-wait на случай, если потребуется опять высылать данные тому же процессу и на тот же сервер-получатель.

Потом уже закрывается насовсем.

Если же коннект в состоянии established - значит его с обоих сторон поддерживают открытым.

Если ты закроешь процесс с любой стороны, коннект исчезнет.

Вроде понял, значит я по сути могу написать разработчику что бы он смотрел тоже.
Я просто даже не мог определить уходит ли вообще запрос от меня или висит у меня
возможно тогда даже, если я правильно понимаю, есть какая то проблема в логике обработки каких-то запросов на самом объекте тестирования

Убрал keep-alive. Не помогло )

вот сейчас получилось 16 зависший потоков. И у всех статус Established

нет возможности на стороне сервера это смотреть?

они у тебя появляются после завершения теста?

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

Всем привет
а можете подсказать как сделать в гатлинге запрос с пустым  multiPart?
Content-Type=multipart/form-data
в рест-ашурд выглядит запрос вот так:

                .when()
                .headers(headers)
                .multiPart("", "")
                .formParams(params)
                .post(URL);

но вообще зависает крнкретный поток, могу предложить еще посмотреть какие условия конкретного потока, врубить дебагеры, выводить в названии семплов номер потока и смотреть после какого места в скрипте возникает проблема. в этом еще может помочь логирование + view results in table (там есть номера потоков)

Всем доброго вечера!
А как правильно писать в разные базы в Influxdb?
Тобишь есть [[graphite]] в конфиге инфлюкса, в котором мы указываем название базы. И вот есть нужда писать в две разные базы

Пока у меня из решений это два графита которые различаются по порту и сообственно по названию базы

[[graphite]]
…
bind-address = ":2003”
database = "base-1”
….

[[graphite]]
…
bind-address = ":2004”
database = "base-2”
….

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