спасибо

странно делать настойку на случай если твой инструмент лагает)

да нет там лагов

есть как-то лучше, ща найду

ну тем паче непонятно полтора часа затупа

нагруза ноль

ctx.getThread().stop() - это вроде конкретный тред закроет

надо бы все

System.exit(1) - во это все нахер заруинит

хмм

спасибо

Не в Teardown же. Просто в потоке.

Thread Group на одну итерацию. Внутри просто
Flow Control Action.

Два варианта сделать отложенный запуск:
1. Таймер Constant timer дочерний к Flow Control Action, на длительность теста +20-30 сек.
2. Просто задержка старта в Thread Group на длительность теста +20-30 сек.

Длительность теста передавать в тест через Property.

Во Flow Control Action есть остановка теста, это проще, чем Groovy.

Thread Group лучше, чем Teardown. Teardown также будет выполняться через 2 часа поле теста. А не через указанный тайм-аут.

+20-30 сек нужно, чтобы последние запросы получили свои ответы

да, верно - не подумал вчера. так проще точно

Еще проблема может быть из-за переменных в таймере или треде

В JMeter есть скрытая логика работы потоков. Точно есть. Так если сделать 250 потоков на 10 минут, постоянное количество. И задать для них 0.8 TPS через Constant Throughout Timer, такую общую малую интенсивность на все потоки сразу.

Это тест стабильности на сверх малой нагрузке, которую и 1 поток выдаст.

То первые 5 минут все 250 потоков будут честно работать, 249 из них не будут ничего делать. А потом с 5-й по 10-ю минуту, 249 будут медленно закрываться. Будет снижение количества потоков. Без снижения TPS/RPS.

Я думаю, что внутри потока есть таймер на бездействие. И он 5 минут.

И вот такие скрытые вещи иногда ломают логику таймеров JMeter под конец теста. Из-за чего в конце теста происходят аномалии

при этом это сработает даже есть повышение интенствности через 10 минут?

Для малых TPS/RPS хорошо работает в JMeter эмуляция открытой модели нагрузки.

Без таймеров вообще.

Если надо сделать Stable-тест, пусть с TPS = 0.3333 TPS. 1 старт сценария каждые 3 секунды.

На 20 минут. То самое надёжное - просто Thread Group, где в
RumpUp нужно поставит 20 минут или 1200 сек.
А в количестве потоков Thread Count поставить 400 (это 1200 * 0.33333)

Так ничего не зависает. Работает точно. Завершается точно в срок + длительность ответа на последний запрос.

Пробовал для такого сценария использовать точный таймер Presice, он вместо стабильной нагрузки делает сначала 0, потом рост, потом поняв, что все нужные tps выбраны засыпает и получается спад.

Throughput Shaping Timer не работает с дробными TPS, на форме ввести можно, но в коде только целые числа. Именно малую нагрузку с ним не получить. У Кирилла как-то получается, но с большой дробной нагрузкой. С малой мало чего работает.

Тут стабильный тест, нет повышений и они не запланированы

Малую дробную получаю через процент в Throughput controller

Вообще с точными рпсами и таймерами явно наблюдается проблема, пытаюсь найти универсальное решение