On 14/11/2007, sebb <[EMAIL PROTECTED]> wrote: > On 14/11/2007, sebb <[EMAIL PROTECTED]> wrote: > > On 14/11/2007, moon <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > I ran a test plan with the following samplers(HTTP requests) under a > > > single > > > thread. > > > 1.Login requests(under once only controller) > > > 2.Sendreceive requests > > > 3.More requests > > > 4.Image requests > > > 5.Next requests > > > 6.Previous requests > > > > > > the above test plan is executed with, > > > > > > Number of threads-1 > > > Ramp-up-0 sec > > > loops-5 > > > > > > and test ran time is 589000 milliseconds... > > > > Which version of JMeter are you using? > > > > > I got the following aggregate report, > > > > > > http://www.nabble.com/file/p13746933/ScreenHunter_124.gif > > > > > > Summary report > > > > > > http://www.nabble.com/file/p13746933/ScreenHunter_125.gif > > > > > > why the throughput in aggregate report and summary report differs? and how > > > is the throughput calculated. > > > > Throughput = number of requests/elapsed time. > > > > The numbers of requests are identical (as are the other columns apart > > from KB/sec), so it looks like the two Listeners are using slightly > > different ways of determining the elapsed time. > > > > It's possible that one of the Listeners is assuming that the sample > > timeStamps are end timeStamps and the other start stamps.
I've found the problem - the statistics calculator used by the Aggregate Report was mistakenly adding the elapsed time to the end time; this had the effect of increasing the calculated elapsed time, and therefore reducing the throughput. The fix will be in the next release of JMeter. The Summary Report has the correct calculation; it also uses fewer resources as it does not need to save all the samples. [It's best not to use the Aggregate Report unless you really need the Median and 90% values.] Although the Aggregate Report shows a lower throughput, the discrepancy will be small, especially for longer test runs, where individual elapsed times are a small percentage of the overall run time. It was more obvious in this case because there were few samples - e.g. only 1 login request; the Aggregate throughput was half the Summary throughput because the elapsed time was used twice by the Aggregate calculation. The TOTAL lines are closer - 2.6 against 2.7 which is about 4% difference. Thanks for reporting the problem. > > [The Aggregate report looks to have the wrong heading; should probably > > be bytes/sec. Or the code failed to divide by the appropriate factor.] > > The Aggregate Graph and Aggregate Report code failed to divide by > 1024; this has been fixed for the next release. > > > If you have a copy of the sampler data (JTL file) could you send it to > > me privately please? Either CSV or XML format will do. [Please don't > > post it to the list] > > > > > Would you explain in detail the throughput calculation for each requests > > > with formula .....plz... > > > > See above. > > > > > -- > > > View this message in context: > > > http://www.nabble.com/How-throughput-is-calculated-in-jmeter--tf4805121.html#a13746933 > > > Sent from the JMeter - User mailing list archive at Nabble.com. > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
