Я тут говорил больше про политику на сервере, когда он игнорирует keep-alive и форсирует вас к установке нового соединения каждый раз. Т.е. мы принимаем несущественными издержки на установку соединения и каждый раз после завершения запроса его закрываем и не держим и не ждем, а вдруг клиент еще что-то пришлет. Кмк это вырожденный случай и мне тяжело сейчас такой представить в реальности.

не, это то совсем понятно и к этому вопросов нет. представим ситуацию, где есть реальная система. подается X рпс, но делается это используя 100 тредов. результаты, например хорошие. а потом вы подаете Х рпс, используя тысячу тредов и результаты плохие.

все треды кипэлайвд

коннект на стороне jmeter закрепляется за тредом - same user each iteration

почему могут быть такие чудеса?)

и это обычное хттп

Ну мы когда-то разрабатывали свои модули ядра, которые перехватывали трафик. И вот ошибки в нашем модуле ядра (если как-то неправильно использовался буфер сетевой карты,я  могу наврать, я уже все забыл) могли вызывать такие интересные вещи. Делалось это тьюнингом через sysctl. :) Но там это было не только к http, а ко всему вообще

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

У нас, даже если откинуть статику (которую мы НЕ откидываем, так как хотим проверять нагрузку на сеть), в бизнес-кейсе 20-30 запросов.

И таких бизнес-кейсов штук 100, например.

Зачем накликивать руками 200-300 запросов, если их браузер накликает сам?

а как ощущалась разница от количества тредов на jmeter? или вы ходили не через прокси

В одном случае никак, у нас была система перехвата трафика. И туда просто проксировался весь трафик, который шел на сервер.
Если система ставилась в разрыв, то таймауты (на jmeter)

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

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

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

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

> Нет уверенности в том, что все операции полезны

Пока нет уверенности что они бесполезны - они нужны.

Мы статику тоже подаём, так как у нас канал интернета лимитирован, и мы хотим понимать, насколько наша система его нагружает.

А значит для нас все запросы - полезны.

@smirnovqa может у тебя были сценарии, когда количество тредов в jmeter при равном рпс влияло на поведение системы?

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

Кэширующуюся статику не записываем.
Но есть ещё и не кэширующаяся.

Хз почему так. Надо повыяснять.

Да, достигал лимита подключений на haproxy.
В приложениях на Reactor и Spring WebFlux количество потоков обработки входящих запросов вообще 20 только. Если есть хоть одна блокировка, например, медленный SQL-запрос, то после 20-ти таких в паралель, 21-й отпадет.

В Tomcat + Spring лимит по умолчанию 250, там сложнее достичь лимита

Для типичных, мне кажется это неактуально, если вы не лезете в сетевую подсистему linux и не "улучшаете непоправимо" какие-то net.* параметры.
Хотя со стороны сервера, я могу придумать как это сделать. Каким-то образом хранить буфер соединений и ограничивать его или еще какую-нибудь магию. Но это тоже уже из области каких-то странных извращений. :)

upd: а нет, про извращения беру слова обратно. Не подумал про кейс Вячеслава