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

Переменная во вторую тред группу никак не передаётся.
попробовал через jsr223 вывести переменную из первой тред группы, но там нет значений.
Пока перенёс запросы в одну тред группу.
Юзер параметр использую, чтобы сразу задать переменную для сравнения с той переменной, что приходит в ответ на запрос.

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

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

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

как то так)

Спасибо!

Так у тебя 100500 запросов из лога?
А как ты их параметризтруешь, если они не связаны?
Или это у тебя не особо требуется?

а что значит 100500 запросов из лога?

параметризирую на максимум

их можно связать, но внутренней логикой, параметризацией, а не бизнес процессами и уровнями абстракций)

Оке, примерно понял

представь что у тебя на входе данные:
api/set - 100 запросов сек
api/tap - 20 запросов в сек и айдишник берется из api/set
api/top - 30 запросов в сек
api/select - 2 запроса в сек, данные генерить так и так
api/search - 12 запросов в сек

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

всегда есть вероятность что бизнес логика не понадобится вообще

А как ваши ребята sla тогда формулируют?

Общие sla на систему это ок, как и на какие то единичные запросы

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

Допустим, один стал медленнее а второй быстрее, на общем rps ты этого не заметишь

ну если api/set входит в бизнес процесс какой, а он стал хуже работать - бизнес-процесс стал хуже

например)