коллеги, всем привет!
у меня немного странная ситуация. получил задание на разработку скрипта, по постановке задачи получается, что в рамках одного скрипта должен выполняться ряд запросов с разными интенсивностями, например для одного виртуального юзера должно выполняться вот так
запросы 1-3 с интенсивностью 1 в час
запросы 4-5 с интенсивностью 1.6 в час
запрос 6 с интенсивностью 0.2 в час
запросы 7-8 с интенсивностью 10 в час
и запрос 11 с интенсивностью 1 в час
и якобы это должен быть именно сквозной сценарий, а разбивать на отдельные скрипты нельзя, т.к. этот вариант уже согласован (хотя техническая возможность для разбивки есть, жесткой привязки к последовательности в этих действиях нет)
в принципе, можно было бы конечно к каждой группе запросов добавить свой throughput timer, но меня смущают интенсивности 0.2 и 10
в худшем случае интенсивность 0.2 может привести к тому, что интенсивность 10 тупо не будет соблюдаться, а в лучшем - большая интенсивность просто будет выполняться неравномерно
как считаете, такой подход вообще имеет право на существование?

там схема на самом деле еще сложнее, например, запросы 4 и 5 должны выполняться с вероятностью 50%, т.е. в одной итерации выполняется запрос 4, в другой 5 и т.д.
но это уже полная дичь

Ну как раз с процентовкой вообще не проблема)

ну так и не разбивай на отдельные скрипты, сделай внутри одного скрипта разные потоки.
поток логина
поток запросов 1-3
и т.д.

так а запросы друг от друга зависят как то?

так в том и фишка, что он сквозным должен быть)

в данном случае требуют 1 скрипт == 1 thread group

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

можно тупо захардкодить тогда

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

+

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

ну типо ты вызываешь первый запрос, потом берешь все остальные в отдельную транзакцию и ставишь что бы они все за час вызвались необходимое кол-во раз (немного рандомизируя время вызова) а на тот который 0.2 ставишь 20% на выполнене

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

> ставишь 20% на выполнение
про это подробнее можно? есть какой то контроллер для вероятности?

посмотри там есть пример такого скрипта

throughput controller

еще можно
Weighted Switch Controller
или просто через if и рандомное число 😂

Я бы на разные катушки поделил.
Для передачи токена в другие катушки можно сделать JSR-223 с ConcurentBlockingQueue, которую положить в Properties. Перед каждым выполнением брать токен из очереди и возвращать его сразу же в конец.

Параметры катушек (два числа) можно читать из user.properties файла - пауза в начале запуска (в сек/мин), нужная интенсивность (в запросах в час).
И длительность теста.

Технически получится один скрипт.
В нем будет очередность запуска запросов за счет регулируемой начальной паузы, ее можно реализовать через Thread Group или Ultimate Thread Group.
И какой-нибудь таймер сделает контролируемую интенсивность.