Throughput Shaping Timer ^{since 0.4.1}

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

1. JMeter test will be stopped when RPS schedule finishes.
2. provide enough working threads for your RPS, JMeter timers can only delay threads (and limit RPS).
3. if you have RPS that lower at the end of test, make threads to lower also. Оtherwise you'll have a spike in last second.
4. avoid using zero RPS value as start of test, this produce spike also
5. avoid zero RPS during the test, this may lead to nasty effects

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".

Example

Example JMX for Throughput Shaping Timer

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 loadprofile_. Property can be specified either in user.properties file (jmeter.properties also applicable), or from command line like -J "loadprofile=..."_. 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.

• const(N, T) - hold constant load of N requests per second for T seconds
• line(N, K, T) - linear increase load from N to K RPS during T seconds
• step(N, K, S, T) - generate stepping load from N RPS to K rps, step height S RPS, step duration T seconds

Duration value in every function may be specified with shorthand case-insensitive modifiers:

• s - seconds
• m - minutes
• h - hours
• d - days

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)