As a planning figure, Flood distributes 500 threads to each load generator (grid node) when running a JMeter test. So the total requests per second (rps) for a given machine will be a factor of how quickly the target site responds to each of those requests. We'd recommend running a test with 500 users as a baseline then observing the rps for that test. That will take into account any latency, target site performance and so forth. Then you can plan to scale out from there.

You can also use throughut shaping timers in JMeter to limit / throttle the rps for a given instance of a running test.

thanks

@koops

. These instructions were helpful. I was able to use throughput shaping timer and a single node and was able to achieve the desired number of rps.

@koops

had a followup question - I have to increment the RPS being sent every 5 mins. I have a throughput shaping timer which does the job of increasing the RPS every 5 mins but flood does not respect the limit/throttle. Is there an optional parameter I need to specify to have it stick to the throttle every 5 mins?

@koops

I also see this warning message (I have specified 3300 threads in the jmeter script)

WARN k.a.j.t.VariableThroughputTimer: No free threads available in current Thread Group ---, made 30 samples/s for expected rps 286.6666666666667 samples/s, increase your number of threads

Hi

@anilaselwyn-nbcuni

(anilaselwyn-nbcuni) - Flood should definitely respect the JMeter load profile you are trying to simulate. An alternative to the thropughput shaping timer is the Ultimate Thread Group which we also support as well. Both should do what you need.

That warning message is JMeter basically saying that it cannot achieve the target throughput with the current number of threads.