Но это не особо влияет , если только синк слать , до 500милисекунд ответ , а то и меньше

На 500+ юзерах

Если у вас синхронный код, то 500мс на 250 rps - это 125 серверных воркеров, не думаю, что там cpu-bound, но если там, например, захватывается на все время сессию в БД - это уже реально стремно

К сожалению я пока не настолько глубоко владею знаниями .. до этого все в одном лупе запускалось и синк и пост.
Но необходимо сделать как можно больше походило на реальные события ...

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

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

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

Не может быть больше 500 юзеров на одном железе ) но да, если около 1к сделать, которые в одном лупе с стеком и пост запросом, начинает время ответа вырастать и отпадать по тайм-аут

А вот эти железки по 500 - они полность между собой развязаны и никаких общих компонентов типа БД под ними нет?

Это вообще разные партнёры и ни как не связаны , у каждого сервера , своя бд

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

Первая сессия стает невалидная

Ну тогда залогинте их отдельно и скиньте в csv, а в остальном сделайте две отдельных тредгруппы на свой тип запросов

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

@exWizard мутный кейс, даже интересно стало. расскажи почему нельзя сделать синк потом пост в одном цикле? у них разные интенсивности?

похоже я знаю как тебя спасти

Разные

это то что показывал Слава, делаем 1 тред группу в ней семпл flow action control - его дочерний элемент throughput controller на 1 запрос в 4 сек (или на максимальную из двух интенсивностей), следующий семпл логин (если нужен единожды для одного треда делаем его в контроллере once only). далее делаем запрос синк - он будет выполняться раз в 4 секунды, далее делаем throughput controller и его дочерним элементом делаем пост. в контроллер даем значение в процентах от максимальной интенсивности, чтобы получить нужную для запроса пост.
итог:
Тред
-флоу экшн
--трупут таймер
-синк
-трупут контроллер
--пост

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

красиво, дешево, классно, с изюменкой

Похоже на правду

охтыж.. Спасибо! сейчас попробую так составить