Throughput Shaping Timer
Long time JMeter users had to try their tests on and on, finding exact number of threads and timer delays that produce desired number of requests per second (RPS) to server. This is "closed workload" approach, and it has major drawbacks (see here why). And if you changed load generator machine or server response time - you were doomed to do all this stuff again.
Here's the solution - Throughput Shaping Timer! Now you can just set schedule of RPS easily, observing it on preview graph. This schedule can be as various as you want. It gives you the happiness of the "open workload" approach.
Few Important Notes
How Many Threads I Need To Produce Desired RPS?
Threads pool size can be calculated like RPS * <max response time> / 1000. The more rate desired the more threads you will need. The more response time service have the more threads you will need.
For example, if your service response time may be 2.5sec and target rps is 1230, you have to have 1230 * 2500 / 1000 = 3075 threads.
It is better to have some threads overhead to handle unexpected response time spikes. But beware of too much overhead, it will lead to "final spike".
Shaping Timer setting in example test plan:
Actual RPS provided:
Special Property Processing
There is a way to specify load pattern from special jmeter property load_profile. Property can be specified either in user.properties file (jmeter.properties also applicable), or from command line like -J "load_profile=...". Make note that this property is temporary, and will be replaced by some GUI setting in future versions.
Load pattern specified with set of function-like declarations. "Functions" may be of 3 types: const, line and step.
Duration value in every function may be specified with shorthand case-insensitive modifiers:
Duration setting may be combined like 1d11h23m6s.
Example of load profile string: load_profile=const(10,10s) line(10,100,1m) step(5,25,5,1h)
On this page: