I wasn't familiar with the Throughput Shaping Timer, it seems like what we need. The only drawback of this solution is that we have some extra threads waiting to be executed.
I will give it a try soon and probably will use it often. On Tue, Sep 13, 2011 at 9:44 PM, Deepak Shetty <[email protected]> wrote: > You shouldnt use Constant timer for such requirements , because that would > need you to know in advance the average time your request responds in - for > you to be able to calculate the delay you need to get the rate of requests > you want > > These type of requirements are met by the constant throughput timer (or by > the throughput shaping timer from jmeter-plugins > http://code.google.com/p/jmeter-plugins/wiki/ThroughputShapingTimer). > > So you should be able to say 144000 samples per minute and "all threads" - > because thats what you want. If you want to calculate it per thread then > you > might be off by a little because they may not all respond the same > (Especially if you have synchronization problems). Youll have to divide > your > wanted number by the number of threads and then specify the value. > > However if you look at the Number of threads you have = 80 , and you want > 2400 requests per second , it means each thread must be able to make 30 > requests in a second - which means your requests on average should be about > 1000(milliseconds)/30 = 33 milliseconds (assuming Jmeter takes no time , > which is invalid when you are dealing with small values and youll have to > factor this in). Depending on what your java request does , such an > assumption may not be correct and you have to increase your number of > threads. however you cannot also keep on increasing the number of threads > for a single jvm instance (if you see that your throughput doesnt increase > with the number of threads and doesnt reach the value you want - you have > to > either tune jmeter or tune your app - or distribute Jmeter but that might > be > problematic depending on what he java sampler does) > > You usually run your test for a long enough duration so that ramp up or > down > is not signifcant. (there's a recent thread in the archives that discusses > this) > > http://code.google.com/p/jmeter-plugins/wiki/ThroughputShapingTimer also > has > some information > > > regards > deepak > > On Sun, Sep 11, 2011 at 11:22 PM, Raghavendra Kristam > <[email protected]>wrote: > > > Hi, > > > > I am using JMeter(2.4) for doing the loading testing of XMPP server and > my > > test plan is configured as following: > > > > - Test plan > > - Thread group > > - Loop Controller > > - Java Request > > - Generate Summary Results > > - Constant timer/Constant throughput timer > > - CSV Data Set Config > > - CSV Data Set Config > > - CSV Data Set Config > > For example : > > Number of Threads: 80 > > Ramp up period: 80 > > Duration: 1800 secs > > a) If I use constant timer = 1000 milli secs then the output as follows: > > Number of samples/Throughput/Avg/Error = 129307 / 71.2/sec / 64 milli > > secs / 0.00% > > b) If I use constant throughput timer, target throughput (in samples per > > minute): 100 and Calculate throughput based on: this thread only then the > > output as follows: > > Number of samples/Throughput/Avg/Error = 214372 / 119.6/sec / 72 > milli > > secs / 12.7% > > > > I need to configure the test plan to get the throughput as around 2400 > > samples per sec (144000 /min 8640000/hr). > > > > Please suggest me what timer should I use > > > > How do I calculate the number of threads / rampup period / constant timer > > values for this. > > > > > > Thanks > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
