Спасибо, Слава! Очень подробный дайджест) по воскресеньям теперь будешь делать такие? Мб где-то Гуглдокс завести, где сразу прикреплять ссылки на треды с описанием? Чтобы тебе не шерстить 100500 сообщений одному

Да, будет здорово, вести треды. Отвечать на сообщения через Reply. Так проще 🙂 отслеживать цепочку.

А если отвечать просто последовательным сообщением, как сейчас 😐, то отслеживать чуть сложнее

Пока попробую по выходным. Если будет сложно - что-нибудь придумаем

Слава - герой, такие объемы обработал) Время писать чат-парсер с автоопределителем темы?)

@Fastmelodic в итоге удалось рпс нужный получить?

Отличная идея, спасибо большое за такой дайджест

Это очень круто!!! Спасибо за большую работу

Интересно что если из комментов ссылки открывать, то не открывает. А из ленты - все доступны

На самом деле проблема подачи низких рпс - решаема, просто тут главное попробовать ряд решений (выбор лучшего, универсального - нет).
Я сделал тестовый пример, пока на Dummy Sampler, в котором 9 разных подходов к реализации низкого рпс, в примере дастигал 0.77 рпс на 7 операциях:
1. "FG" - Throughput Shaping Timer (TST) является дочерним элементом первого запроса, внутри которого стоит значение в 0.11 рпс
2. "SG" - TST в корне TG со значением в 0.77
3. "TG" - TST дочерний элемент Flow Action Controll'a с рпс = 1.1, а 7 операций - дочерние элементы Throughput Contoroller'a в котором выставлен процент = 10 (10% от 1.1 = 0.11 и домножить на 7 операций=0.77)
4. "FG2" - Аналогично п.3, но рпс = 11, а процент = 1
5. "FF" - Constant Throughput Timer c значением 46.2 рпм , все элементы в корне (режим all active threads in cur. tg (shared))
6. "SG" - Аналогично п.6, но CTT - дочерний к первому элементу и у него значение рпм 6.6
---
выше используются только дефолтные тред группы
---
7. "tst1" - Concurrency Thread Group (CTG) с функцией ${__tstFeedback(timer1,1,10,1)} где TST дочерний элемент первого запроса с значенеим рпс = 0.11
8. "tst2" - TST в корне со значением 0.77
9. "tst3" - тоже CTG c  ${__tstFeedback(timerN,1,10,1)}, но TST - дочерний элемент Flow Control Action'a имеет значение = 11 рпс. А все запросы убраны под Throughput Controller с процентом равным 1.
---------------------
Итого результаты за 5 мин теста (первый скрин показывает 6 минуту, но в каждом таймере установлена длительность в 5 мин) (целевой показатель 46.2/min):
1 скрин для всех дефолтных тред групп выставлено количество потоков = 1, тут оказались близки tst2, FF, FG2, tst3, TG (FF ближе всех)
2 скрин для всех дефолтных тред групп выставлено количество потоков 10, тут видна зависимость CTT от количество тредов и видно, что переизбыток тредов критичен для TST. тут близки были: FF, tst2, tst3, FG2 (FF ближе всех)
3 скрин для всех дефолтныз тред групп кол-во потоков = 100, tstFeedback для всех CTG выставил функцию так: ${__tstFeedback(timerN,10,100,10)} . тут наглядно показано, насколько сказывается неправильный выбор количества потоков для реализации нужных рпс. ближе всего снова был FF, приблизился к цели еще tst3 - остальные аутсайдеры.
Отдельно хочется отметить, что таймеры CTT - не очень честные, так как изначально они подают сильно повышенную нагрузку, что заставляет в последствии их ждать длительные интервалы - а значит распределение не очень верное, но это всё, как можно наблюдать, к 5 минуте теста выравнивается.

Скорее всего по описанию нифига не понятно, поэтому можете в сам скрипт глянуть (нужно поставить Dummy Sampler из плагина)

к слову для тест планов с задержками (констант таймеры внутри теста) - совсем другая картинка. точно также как и нагрузка на сервисы с очень сильным разбросом откликов. из опыта - верная конфигурация tstFeedback в 90% случаев дает хорошее приближение с погрешность до 10%

с десктопа - ок

да, ну да ладно, на качество не влияет)

про "беуспешно пытались сделать дробный малый RPS с ThroughputShapingTimer (это невозможно, тут нужен Constant Throughput Timer)"  - апнул тему по ссылке, сравнил возможные подходы и решения https://t.me/qa_load/38159

Хм. я делал через ThroughputShapingTimer, посчитал целевой RPS, умножил на 100, и потом выполнял каждый 100 запрос. Не помню точно как именно я "делил". Но целевые 0,05 RPS я получал стабильно. Причем у меня в таблице ThroughputShapingTimer был часовой график с точностью в секунду, и RPSы были реально маленькие. Всё работало корректно.
(повторял нагрузку с прода 1:1)
0,05 было не всегда, там плавало сильно, где то 10RPS, где то 0,05

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