Зачем параллелить что-то в контроллере

Почти в любой тред группе можно настроить количество виртуальных пользователей(потоков)

в задаче поставили почемуто использовать именно parallel controller

щас уточню причину

я ж говорю не нужно использовать паралель контроллер) есть очень очень редкие случаи когда он реально нужен

Согласен с Кириллом, больше проблем чем пользы

так. понял. щас попробую удалить параллел контр

Всем привет. Интересный кейс. В jsr sampler реализован подход rpc для rabbitmq. И проблема в том, что в concurrency thread group + tst function + throughout shaping timer после определенного порога (скажем в 100 рпс) время выполнения сэмплера начинает увеличиваться, при этом расходуются все доступные треды. Но что самое важно - поставил метки времени выполнения разных этапов в этом сэмплере и вижу, что треды просто подвисают в ожидании, а само выполнение в пределах нормального ~100 мс. И ещё одно наблюдение - этот скрипт в обычной тред группе с throughput shaping timer дают 400 рпс и для этого используется всего до 10 тредов . Есть идеи?))

Тред группа ж выполняет запросы внутри последовательно

а мне нужно шоб был рандом

рандомный порядок выполнения запросов или выполнение рандомных запросов? не совсем понимаю

рандомный порядок

то есть первый юзер выполняет запросы в порядке 1-2-3-4-5, второй юзер 2-4-1-3-5, третий юзер 5-3-4-1-2 ит..д.?

а какая разница приложению в каком порядке у тебя один тред выполнит запросы? мне кажется тебе надо прокачать теорию минимально.
даже при обычном росте тредов у тебя будет такая картина:
время: 1-ая сек. |  2-ая сек.  | 3-ая сек. | 4-ая сек ...
1 тред: 1 запрос | 2 запрос | 3 запрос | 1 запрос ...
2 тред: ждет         | 1 запрос | 2 запрос | 3 запрос ...
3 тред: ждет         |  ждет        | 1 запрос | 2 запрос ...
за каждую отдельно взятую единицу времени запросы в систему будут приходить смешанные и рандомные так как нагрузка идет по параллельным тредом которые не синхронизируются ни в каких точках

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

для наглядности тем кто с телефона

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

поэтому и приходится использоать parallel controller

как видно из трека, все запросы последовательны

там мб рамп ап стоит 1 секунду?