С user_parametrs не годится вариант, так как логин_степ отличается Резов и НЕрезов, и потом уже на логине данные два Реза делает множество логин_транзакций что для выполнения последующих запросов получаю ошибку 410 Session is displaced. Буду делать вариант который посоветовал @login40k

Ах да. Очень важный момент. Вот мы задали профиль

1) 10 стартов сценария в сек
2) 20 стартов сценария в сек
3) 10 стартов сценария в сек

Сколько это запросов в сек?

Пусть у нас в сценарии 7 запросов. Которые выполняются всегда, кеширования нет.

А. 10 стартов сценария в сек даст 10 запросов в сек?

Только первый запрос сценария будет стартовать с интенсивность старта сценария. При Loop Count = 1. Остальные запустятся после его выполнения, после выполнения предыдущих.

При Loop Count = 10 даже интенсивность старта первого запроса не будет равна интенсивности старта потоков. На первой итерации да, а на 9-ти других уже нет. В среднем - не будет равна.

И в моменте интенсивность запросов точно не будет 10 RPS. Но на большом промежутке времени (10 минут) средний показатель RPS для каждого отдельного запроса будет 10 запросов в сек. А RPS выдаваемый всем сценарием посчитать так нельзя.

Б. 10 стартов сценария в сек из 7 запросов даст 70 запросов в сек?
Снова нет. Если внутри катушки не применять Parallel Controller, то запросы будут выполняться последовательно. Эффекта умножения не произойдет.


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

Исключение. В сценарии ровно 1 запрос. Тогда интенсивность старта будет равна RPS. И тогда нужный RPS можно получить с помощью простой Thread Group.

Я не владею техникой расчета RPS. И профиль составляю по стартам сценария в сек. С RPS есть особенности, которые нужно исследовать.

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

UPD: аналогичная картина после замены полезного сэмплера на дамми

теперь проект выглядит не как нагрузочный, а как дичь какая-то

Выглядит как ошибка округления. До пула кратного 8-ми (96 RPS первые 30 минут). А потом корректировка. Если сразу задать 96 RPS, то возможно, ошибка не накопится.

Такая гипотеза

Это норма. Меня больше удивляет, когда у интегрирующихся с банковским сервисом подписание доков перед отправкой выполняется на инфокриптовом токене воткнутом в usb.

похоже да. при задании тпса 104 картинка приятнее, но тоже кривовата. как бы ее починить для получения ровно 100?

похоже да. при задании тпса 104 картинка приятнее, но тоже кривовата. как бы ее починить для получения ровно 100?

Для ровной стабильной нагрузки удобно использовать
Constant Throughput Timer, который задает общую интенсивность для всех потоков в текущей Thread Group.
То есть связка:

Thread Group с количеством итераций - бесконечность и длительностью в поле Длительность, пусть 3600 сек
* Flow Control Action + Constant Throughput Timer на все потоки катушки с заданием общей интенсивности в виде 100*60 = 6000
* прочие запросы

Сорри за офтоп. А для чего такая точность?

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

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