Спасибо) усе усёк)

спасибой просто так не отделаешься) давай зашквары из своего опыта

В тредгруппе лежит, на все запросы группы получается. Попробовал без рандом таймера и похожая картина, 0.6 рпс при заданных 0.77..

так, ну это очень тонкие материи - эти ваши низкие рпсы

короче варианты решения, стоит пробовать по очереди исмотреть результаты могут как прирост дать так и ухудшить, какие то могут только в связки сработать:
1. необходимо таймер делать дочерним элементом одного из запросов или дочерним элементом flow action control и высчитывать интенсинвость относительно этого элемента, остальной тест подтянется к этому запросу. то есть если 7 элементов в корне теста, то первом уэлементу делаем 0.11 рпс дочерний таймер и будет  0.77 у всего теста.
2. чтобы уйти от низких рпсов, можно сделать ужасное! кладешь весь свой тест в throughput controller и выставляешь ему настройку 10 процентов, на тот же уровень что и контроллер клади flow control action и выставляй ему интенсивность 7.7, jmeter будет частично молотить в холостую - это может немного повлиять на производительность. также можно сделать 1% и 77 значение таймера.

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

Короче
Забиваешь на удобство (на throughput shaping timer)

И для считаешь сколько тебе нужно потоков и как часто должен молотить каждый

Для контроля количества по оков юзаешь ultimate thread group, для управления производительностью каждого потока - flow control внутри которого лежит constant throughput timer

https://loadtestweb.info/2017/08/23/pacing/

И будут тебе точные rps

Добрый день.

Может кто подскажет если не сложно)
Кратко прошел тест, он не очень радостный + на графиках мониторинга железа вообще ничего, как будто ничего не происходило.
Возможно мониторинг железа не корректно настроен.

Может кто по AWR отчету по быстрому проконультирует?)

Вопрос такой, есть
DB Time(s) - Сумма времени утилизации процессора и время ожидания (без простоя) (что логично из названия)

Можно из этого приблизительно определить на сколько была загружена CPU DB процентно?
Или по какому то др. параметру процентную загрузку определить?

Я бы сказал по последнему скрину, но usr + busy + idle+ sys != 100% и по этому я сходу про загрузку cpu процентно сказать не могу четко

Но может кто имеет уже такие знание как это прочитать

А вот в простое
Может кто знает, где прочитать почему
usr + busy + idle+ sys != 100%
?

Busy и есть Usr + Sys + Wio

Условно, твои ЦПУ базы были утилизированы в ходе этого снепшота в среднем на 26.14%

Idle - это "свободно" или "простой", грубо говоря

Спасибо!!
Точно) busy это Usr + Sys + Wio и тогда все сходится.
Тогда в с бд во время теста все норм, значит по какой то др. причине система не потянула нагрузку...

Это тоже спорно. У базы есть еще и софтварные ограничения (например органичение по сессиям).

Плюс нужно смотреть в AWR в раздел SQL Statistics - там много интересного (что было в топе, что больше всего грузило ЦПУ, что дольше всего работало и так далее)

Но в твоем случае, скорее всего, не в базу уперлись..