|
ThroughputShapingTimer
Throughput Shaping Timer since 0.4.1Long time JMeter users had to try their tests on and on, finding exact number of threads and timer delays that produce desires 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". ExampleExample JMX for Throughput Shaping Timer Shaping Timer setting in example test plan: Actual RPS provided: Special Property ProcessingThere 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) | |
|
|
Hi
How can we determine maximum number of threads required to generate certain amount RPS? For e.g. I want to achive 1000 RPS, how much threads should i define in jmeter?
Regards Anubhav
Hi, I added notes on threads pool calculation to doc.
Thanks
I must say I love this feature. It enable testing using open workload (with rps) instead of closed workload( with number of users). The response time of the system will be mucher higher in open workload in theory.
Good jobs!
The formula for thread count calculation states "RPS <max response time>/1000", but the provided example "2500 1230 / 1000 = 3075" swaps RPS and <max response time>. Mathematically this is correct, but could be confusing to some readers.
Thank you very much! Fixed!
I need to run a RPS load for a long time, like 1-Week, but the Duration is specified in Seconds. I have found that even specifying just 20 hours in seconds (72000) causes JMeter to either freeze, or just takes far too long to adjust the graph (after a Clear All) and become responsive to new user actions for me to wait.
Am I missing something? Are these longer durations feasible with this timer?
Thanks in advance, David
David, I think you don't miss anything, the graph maybe performs poorly with so long tests. Could you create an issue at issues tab? Mention there that you need some shorthands for duration (12h, 7d etc) and better graph performance. Just for me to remember to fix both problems!
Thahk you!
Hi,
Fairly new to JMeter and definitely to this plugin.
I was wondering how the test plan would look like if their are many transactions, each with its own frequency. Should I create a separate thread group for each transaction, or should I combine them somehow in one thread group? What would be the best practice?
Thank you!
For open workload tests the better way is to use single Thread Group with enough threads and single Raw Sampler reading requests from pre-generated file. JMeter's problem with resources is because it do too much work generating data in runtime. Pre-generated data is the key for high-rate testing.
Do you mean the "HTTP Raw Sampler" from the JMeter Plugin?
And what is the best practice to divide the overall throughput for the thread group among the samplers? Should I use a "Throughput Controller" with percentages?
Sorry, I don't know if Throughput Controller will help you here...
Thanks for your response. I am still trying to figure out what you actually meant. I guess you meant to use a HTTP Raw Sampler with a Raw Data Source available in the JMeter Plugins. The brief documentation sais it "allows load testing with huge datasets at high request rate". That part is clear and the way I want to go.
Though, you mention to run a single Raw Sampler. How can I use a single raw sampler for multiple different transactions, each with its own pre-defined throughput? Please enlighten me!
The key is your pre-generated raw data file. You should generate it containing transactions with frequencies you want. So if you want 40% of your request to be tran1 and 60% of them to be tran2, the file should have those requests uniformly mixed in that proportion. Raw Data Source will read the file sequnetially, so sampler in each thread will send the requests in the proportion you generated...
Yep very clear, the difficulty becomes creating that file. Thanks for your help!
Ah one more question. Is there any way to put dynamic data in the requests at run-time? For example, I need to put the current time in one of the query string parameters. Guess not, but just asking...
For data read from file - no. But it's the choice - either fast or complex logic.
Yes I understand. Another issue is that the unit in the binary file is an HTTP request, while in my test plan the unit is a transaction (which is composed of multiple HTTP requests). That will mess up the throughput which is bound to a transaction. Hmmmm.
So Raw Request is not applicable here. Using JMeter native samplers out of this project scope.
I am not sure what you mean with out of project scope, but I can still use native sampler's with Throughput Shaping Timer.
Sure you can. But dividing throughput between samplers still your task.
Back at the problem I started indeed. For others, dividing throughput among samplers can be done by the native Throughput Controller with a percentage of the global throughput for the thread group assigned to each sampler. Alternatively, one can scope the Throughput Shaping Timer at the sampler instead of the thread group.
What is the inter arrival time distribution of the shaping time produce? Exponential(Poisson arrival of requests)? It seems the shaper will produce rather bursty traffic from an experiment setting( 100 threads, 40 rps, 0.004sec response time(processing time actually))
If I try to make a 24-hour schedule JMeter hangs. It was mentioned before in this thread that the graphs take to long to calculate. Is this fixed already?
Please, give us some details: which version of plugins do you use and which exact schedule do you set?
Can this timer be used with any thread group or only certain ones? And for thread groups, does the runtime for thread group have to match this timer to some extent (longer, same duration, or shorter than timer schedule total). Like can this be used with a standard JMeter thread group set to loop forever or X loops (or will you have to set a schedule if using standard thread group)?
Yes, this timer can be used with any thread group. When thread group finishes early than shaper schedule - that's it, we have nothing to shape. When shaper schedule finishes before threads (eg you have forever loops) it will ask JMeter to stop test.
Is this timer typically better used outside of thread group or in a thread group? The example shows it global to the test plan.
It depends on your requirements. As usual JMeter timer it can be placed anywhere in Test Plan and will affect corresponding scope.
How to do less than one request per second? I enter a decimal and it just seems to go as fast as possible.
Take a look into issue 115 , maybe we'll have the support for non-integer rate