Вот такой сценарий например  , пользователь открывает журнал загружается список документов , открывает один док , редактирует его возвращается в журнал. По твоему между открытием дока и журнала не нужно выставлять таймеры хотя бы минимальные а просто малым количеством юзеров долбить за счёт rps ?

И удобно же смотреть на графиках зависимости , изменения времён отклика от количества тредов

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

Вот я и говорил, что в логике Jmeter's поток это реальный пользователь. Который КОНЕЧНО виртуальный. Но 1 поток должен по возможности имитировать 1 пользователя.

мое понимание

Коллеги добрый вечер хотел задать вопрос, сколько надо памяти для джметра если нужна нагрузка около 75000 RPS ? Один тред в нем 50 запросов http reuqest + groove post/pre prossor, сложной логики нет , get/post запросы. Сценарий сделан только на 1/5 этой мощности, так как предпологается запустить с одного сервера 5 джетров. Памяти на тачке 512 гигов + на нем будет крутится инфлюкс с графаной? (Не я такой а жизнь такая) Нужен совет

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

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

Я пока не охватил необъятное. Но скорее будет лимит по сети и кол-ву портов, поэтому нет смысла на одной машине запускать несколько Jmeterов, даже если она справиться по ядрам и памяти. Если Вячеслава слушать. =)

Вот еще актуальный (для меня) вопрос: запрос байты, ответ мегабайты. Даже если >dev/null то через четь эти мегабайты все-равно тащить надо. Что делать?

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

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

похоже Andrew прав, одной машиной не обойтись

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

Да всё понятно, нет возможности попробовать😭 .

ну звучит так будто вам точно не хватит)

и памяти и вообще всего

а если использовать java implementation в http request ускорится джеметр?

@jigarkhwar @chepk подскажите, нет ли примера работы с хедерами кафки в gatling-kafka-plugin

вот тут Слава очень классное сделал исследование

В наш плагин добавляли поддержку

Как с ними работать честно говоря не сильно в курсе