Bug 29481 - Saved Aggregate Report is Different from original when reloaded
Saved Aggregate Report is Different from original when reloaded
Status: RESOLVED FIXED
Product: JMeter
Classification: Unclassified
Component: Main
2.0.0
PC Windows XP
: P3 normal (vote)
: ---
Assigned To: JMeter issues mailing list
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2004-06-09 21:41 UTC by udele
Modified: 2006-05-25 15:40 UTC (History)
0 users



Attachments
Sample jtl file for calculations (8.25 KB, text/plain)
2004-06-10 14:49 UTC, udele
Details

Note You need to log in before you can comment on or make changes to this bug.
Description udele 2004-06-09 21:41:28 UTC
If I save the aggregate report results of a test to a jtl file, reopen it in 
another aggregate report listener, and compare the results, some of the 
numbers are off.  The numbers for one url is completely wrong while the others 
were calculated correctly.  I was able to reproduce this several times, 
however I have not tried this with other types of listeners.
Comment 1 Sebb 2004-06-10 12:37:50 UTC
Could you perhaps attach a sample JTL file that shows the problem?
Comment 2 udele 2004-06-10 14:49:44 UTC
Created attachment 11814 [details]
Sample jtl file for calculations
Comment 3 udele 2004-06-10 15:24:04 UTC
I've attached a sample jtl file.  Out of curiosity I opened up the jtl file in 
two separate Aggregate reports in a new Test Plan.  The only difference 
between the two reports in the new plan seems to be the Total in the Rate 
column.  The difference appears more pronounced between an aggregate report 
that is generated directly from a test run and a saved report.  
Comment 4 Sebb 2004-06-11 00:24:01 UTC
Can't see any obvious problems when loading the JTL into two different 
Aggregate Reports - apart from an extraneous "/" in the Totals Rate column.

Looking at the data shows that the /login URLs are different from the others, 
in that they include two sub-results each. This is because /login returns a 
302 - redirect temporary. This may be the cause.

If you can recode the test to avoid the redirect, it would be interesting to 
see if this changed the calculations.

Could you give a bit more information on what figures you think are wrong?
Comment 5 udele 2004-06-11 15:58:52 UTC
Thank you seb!  Once I stopped following redirects in my test plan, the 
problem went away.  For the majority of the time, the rate was being 
calculated differently for the /login page.  Occasionally, I would see the 
min, max, and average off too, but I can't reproduce that as easily for the 
same page.  I would like to be able to follow redirects (specifically for 
viewing in my results tree), but I can live without it for now.
Comment 6 Sebb 2006-05-25 22:40:51 UTC
Finally discovered the problem: when subresults are initially added to main
result, the elapsed time for the main result is accumulated.

However, when the results are read in from a file, this calculation has already
been done.

Fixed in 2.1 branch for both old and new XML format result files
[does not affect CSV results, as subresults are not saved]