твои пользователи вообще в мире не существуют, они тыкают так быстро как позволяет твоя машина

один твой юзер это армия бабушек

ааххах, то есть один юзер которого я симулирую заменяет много реальных юзеров и получить реальную цифру сложно?

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

т.е. бороться с этим бесполезно - он так работает и нет возможности сказать: "ну подождал и подождал, нет ни чего страшного, не торопись!"?)

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

например путем увеличения юзеров

а какой таймер сейчас используется для интенсивности?

понял. спасибо. поиграюсь с задержками и количесвтом юзеров)

задержки?) надеюсь ты к каждому запросу не делал ожидания

)) нет

тогда вот вопрос который сможет помочь

сейчас нет таймера. интенсивность задается через Throughput Controller, количество юзеров и время теста

очень странный подход, а откуда ты знаешь сколько запросов в секунду выдает такой тест? опытным путём?

в таком случае задержки и увеличения пользователей не помогут

тебе нужен например throughput shaping timer

тогда за интенсивностью будет кто-то следить)

у меня есть данные с прода по интенсивности запросов и количеству обращений к сервисам за определенный промежуто к времени и конкретные сценарии работы. Проценты по тому или иному сервису посчитать не сложно. Завернуть все это в  Throughput Controller и сказать ему сколько % от общей нагрузки он займет. Осталось только воспроизвести все на стенде. И вот тут jmeter после долгого ожидания начинает "долбить как пулемет". и портит всю статистику))

+

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