есть несколько режимов аггрегации коннектов, можно иметь 1к1 входящего потока и выходящего, можно пытаться на выходе обходится минимумом коннектов. смысл в том что как Илья правильно писал - потеря трафика это не про http-запросы, если надо имитировать близкие к реальным условия. Слава кинул хорошую тулзу - clumsy, вот там верный подход

а матчинг коннектов наверное все таки должен быть как на проде, если прокся в объект тестирования входит :)

Немного разверну ответ коллег:

Некоторые компании выбирают lr вместо бесплатных jmeter/gatling потому, что им время важнее денег.

Дело в том, что в lr есть рекордеры под протоколы более сложные, чем обычных http и его вариации.

Например, жметер умеет подавать нагрузку по вебсокету или на базы данных  (с плагинами).

Но вот что должно быть в этой нагрузке?

Если нужно нагружать, отправляя 1-10 известных вам запросов - вы напишете их руками.

Но если такой протокол это основной протокол в вашей системе - вы столкнётесь с проблемами.

Мы тестировали двузвенку, состоящую из БД и толстого клиента.
Только на этапе входа в систему клиент отправлял 50-100 запросов.
Для жметра мне пришлось бы отлавливать их профайлером, вручную переносить в жметровый скрипт и параметризовать.

А это только логин!

Lr делает большую часть этой работы за меня.

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

Конечно, если у вас есть суперопытные тестировщики, которые по опыту уже наполовину разработчики - они могут написать парсер трафика и автоматически конвертить его в скрипты.

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

К тому же, таких опытных тестировщиков не так уж и много.

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

Ты про балансёры типа хапрокси?

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

Я вижу следующие варианты:

- у тебя мало разных запросов, их проще сделать руками
- ты записываешь трафик, просто не родным рекордером (har из браузера или парсинг логов веб-сервера)

это варианты чего?

В каких случаях не нужно записывать трафик

не понял, а до этого оно будет важным почему?

Ну мне кажется, Слава косвенно отвечал на это в своем видео про ускорение jmeter. Если у вас постоянное соединение, в какой-то момент упретесь в системное ограничение и если клиенты медленные, то это будет вашим естественным ограничением для пропускной способности.
Если keep-alive убираем, то получаются накладные расходы на установку соединений и здесь, кмк, важно понимать чтобы эти накладные расходы были сильно меньше полезной нагрузки, т.е. чтобы сохранение соединения не давало преимуществ.
Надеюсь понятно написал.

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

не совсем понял, а какая разница для конечной системы медленные клиенты или нет. я могу их сымитировать условной в одном потоке с keep alive и могу в 100 потоках. в систему прилетит равное количество рпс, она создаст столько коннектов с проксей сколько им нужно и тд

У тебя вроде каждый запрос - это транзакция, а последовательности запросов не очень длинные?

Ну, в такой ситуации может и проще руками накликать.

Но бизнес-кейсы, где нудно подать 20-50-100 запросов в конкретной последовательности это очень частый кейс в НТ. И не стоит накликивать их руками, если можно этого НЕ делать :)

Я так понял твой вопрос:
Ты интересовался, как влияет количество потоков жметра на работу балансировщика.

Я неверно тебя понял?

Туплю утром, не выспался :)

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

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

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