Да, записываю кейс целиком и этот кейс подаю с нужной частотой.

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

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

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

Ну, идеально честным он, конечно, быть не может.

Мы по бд видим количество бизнес-кейсов.

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

И мы сравниваем утилизацию ресурсов на проде и в тесте - и для одинаковой нагрузки она примерно одинаковая. Так что довольно честный :)

Да, не очень важны. Но для HTTP

Если будет тест на PostgreSQL например, где лимит в 100 подключений. То создав 101 поток в JMeter мы достигнем лимита сразу. Утилизируем память на сервере. Но больший вклад в производительность дают SQL-запросы.

Для IBM MQ и RabbitMQ количество потоков очень важно. Чуть больше подключений и все MQ зависает.

А вот для HTTP REST через балансировщик не так важно количество подключений. Расходы на обработку подключений сильно меньше расходов на обработку запросов.

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

Хорошо. Даже в такой ситуации - вот есть у тебя 100+ запросов. Зачем их писать руками, если можно не писать?

Ведь у каждого запроса есть заголовки / параметры, многие должны идти в конкретной последовательности.

Конечно, их придётся параметризовать руками.

Но зачем их руками переносить из сваггера (или что там ещё) ?

соглашусь. но к общему удивлению скажу, что в моей практике был кейс когда потоки были важны, с учетом двух "балансировщиков" (HAProxy + IIS), внутри каждого из которых я не нашел проблемы. а приложение было черный ящик. мою веру в не важность потоков это пошатнуло)

зачем - я писал 2 раза выше. ты сильно усложняешь процесс. Import curl прям из сваггера, где все за тебя уже ввели

Кстати, вот сейчас после этого уточнения у меня появился другой пример. Вот смотрите, у меня сейчас есть кубкластер, в котором живут полезные сервисы и мальчиш-плохиш Keycloak. Плохиш, потому что максимально эффективно из всех остальных утилизирует CPU, и отбирает конфетки CPU ресурсы у других сервисов. И вот для 100 потоков, он не успевает сожрать столько ресурсов и полезным сервисам хватает мощности на свою работу, но с ростом потоков, он начинает их вытеснять с полянки. Т.е. у нас CPU становится ботлнеком.
Т.е. если я захочу проверить сколько максимально выдержит полезный сервис (и если нет возможности зайти в него без авторизации), то мне придется ограничивать кол-во тредов, чтобы не инициировать новые авторизации, а увеличивать кол-во полезных запросов внутри одной сессии. Ну или всех авторизовывать, а потом раздавать всем токен (например). Опять же, вырожденный случай.

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

а ты ходишь в него напрямую?

у тебя похоже кейклок не за проксей всё таки

да, без прокси. Но вроде там выше уже тоже контекст сменился на безпроксевый, если я правильно понял. А чисто x тредов хорошо, 10*x тредов плохо

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

тут что угодно почти было бы чувствительно к коннектам на самом деле

а, тогда да. Согласен, просто когда читал, видимо не отследил мысль. :)

:)

Воот.
Мы пришли к тому, что трафик пишется импортом.

Есть такой же импорт для бд или вебсокетов?

Я не видел.
И приходится все запросы руками копипастить/набирать