да у меня тоже TST работает корректно на всех рпсах

Написал про то, что это невозможно, потому что считал, что внутри таймера Throughput ShapingTimer используются только целые типы. И минимальный RPS = 1 RPS.

И я был не прав. Посмотрел на исходный код таймера снова. В нём int для RPS используется только при отображении графика в GUI таймера. А для расчета, внутри, используется тип double. Поэтому RPS вида 0.05 отобразится в GUI как 0, но будет использован при расчетах как 0.05.

кстати в non-GUI будет на TST + CTG будет точнее процентов на 12 в среднем по каждому варианту, что очень хороший прирост. при этом проблема чуть пониженных рпс в данной реализации присутствует и Андрей Похилько в курсе. На более ранних версиях jmeter такого не было, замечено было в 5+ версиях, "недострел" где-то 3-5% бывает

может фикс в дайджесте сделать или в новый пойдет?

патч)

Самый точный RPS для повышающейся нагрузки в условиях изменяющегося времени отклика получил только с Constant Throughput Timer с настройкой, что он действует только на один поток = this thread only. Его простота в том, что в нем нет обратной связи, он не корректирует количество потоков в зависимости от времени отклика. Он просто использует все. Поэтому одинаково ровно работает как в начале теста, пока система быстрая, так и в конце, когда она зависает.

Он может работать в режиме обратной связи all active threads in current thread group (shared) - на все потоки. В этом случае его работа зависит от последнего выполнения сценария:
as above, but each thread is delayed based on when any thread in the group last ran

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

Поэтому таймер с обратной связью Throughput Shaping Timer я бы рекомендовал для тестов со стабильной нагрузкой. Или для систем со стабильным временем отклика. Или для тестов где четко выставлен Timeout на ожидание ответа и на подключение и таймаут маленький. Иначе такой таймер будет отставать, запаздывать, корректироваться на высоких ступенях нагрузки. И это нормально.

А для нагрузочных тестов (с растущей нагрузкой) простое и стабильное решение - Constant Throughput Timer в режиме this thread only. И это проверял.

Конечно, в выходные. Давай ты напишешь

таким образом в новый пойдет, я понял. давай попробуем

Дополнительный способ выровнять нагрузку - использовать таймер и на TPS и на RPS, вот тут так попробовал с двумя Constant Throughput Timer:
https://t.me/qa_load/36726

Это как нагрузка + trottle в Gatling - сразу и TPS и RPS контроллируем. Только в Gatling у trottle приоритет над профилем нагрузки, он задает и длительность всего теста.

А в JMeter если использовать два таймера, то приоритет срабатывает проще - приоритет лишь на интенсивность, а длительность теста таймером не контролируется.
Например есть два таймера
1) Таймер на все запросы внутри Thread Group - он для RPS пусть 0.1 RPS - это как гибкий Timeout в 10 сек на ожидание ответа, 0.2 RPS будет как таймаут в 5 сек.
2) Таймер внутри первого Flow Control Action для контроля TPS, для этого Flow Control у него больший приоритет, он переопределяет собой первый частый таймер.

Думаю, что такое же можно сделать с двумя Throughput Shaping Timer и получится гладкая нагрузка, при времени отклика в пределах заданного в таймере RPS шага.

Способ с двумя таймерами тоже имеет ограничения. Его не получится применять если в сценарии переменное количество запросов из-за циклов, условий и вероятностей. Но если RPS стабильный в одной итерации, то способ дает отличный результат.

Недостаток - больший шаг нагрузки для TPS и большее количество потоков. Пусть задано 0.2 RPS (как шаг в 5 сек между запросами), а всего в сценарии 50 запросов. Получается, что даже если запросы не зависнут на весь сценарий нужно будет 250 сек минимум. И надо задать шаг нагрузки в таймере TPS как 1/250 или 60/250 сценариев в минуту. При таком малом значении может понадобится много потоков. Если нужно просто сделать 1 TPS уже надо 250 потоков, а если нужно всего 4 TPS - то 1000 потоков. Иногда это не проблема. И нагрузка получается гладкая.

похоже это будет почти открытая модель

можно же таким образом пейсинги делать

Это бесконечная история. Про таймеры и модели. Можно стремиться к гладкой нагрузке. Но окажется, что хочется делать и всплески, так как в реальности все не гладкое, а волнистое.

Поэтому можно использовать любые таймеры, пусть неточные, но несколько тестов, у которых разная цель:
1) Сначала грубо определить ступень максимальной нагрузки
2) Сделать тест подтверждения стабильной нагрузкой
3) Сделать тест с более волнистой нагрузкой но тем же объемом операций, что в тесте стабильности - стресовое

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

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

во-во, так меня и соблазняли

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

Добрый день. Пытаюсь найти ответ на вопрос может ли Jmeter работать с localstorage (в сценарии шлётся post запрос с логами в параметрах которого значения из local storage). Быстро, почти везде, гуглится один ответ:
"JMeter is not a browser ..."
"Using Selenium with JMeter's WebDriver Sampler"

получается только через selenium можно будет работать?
или есть ещё способы?

Не умеет. Но можно имитировать работу. Использовать переменные jmeter и Post Processor, Pre Processor, чтобы повторить логику JavaScript. Или явно вызывать Java Script, но в нем сохранять значение не в LocalStorage, а в переменную.

Раздобудьте полную версию js-файлов, без минимизации и обфускации. И переделайте их под себя. И JSR-223 позволит их вызвать

Думаю JS не понадобится даже

Пока удалось реализовать по средством ultimate thread group и constant throughput timer`а, агась)