Bug 40791 - Calculator used by Summary Report is inaccurate
Calculator used by Summary Report is inaccurate
Status: RESOLVED FIXED
Product: JMeter
Classification: Unclassified
Component: Main
2.2
Other other
: P2 normal (vote)
: ---
Assigned To: JMeter issues mailing list
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2006-10-18 13:07 UTC by Rub
Modified: 2006-10-20 16:35 UTC (History)
0 users



Attachments
Calculator.java patch to take min and max of startTimes and endTimes into account (769 bytes, patch)
2006-10-18 13:10 UTC, Rub
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Rub 2006-10-18 13:07:05 UTC
Calculator.java used by SummaryReport uses the startTime of the first sample as
start time for it's own calculations. First sample to arrive to summary report
is not always the first sample in time because some operations may have started
earlier and will arrive later because the sample come from a jmeter-server (in
distributed testing with batch mode this is noticiable) or because the time to
complete the sample locally is high. 

Furthermore Calculator (and Summary Report) take the endTime of the last sample
to arrive as the endTime for all SummaryReport calculations. This is worse
because  in distributed testing the time is not always synchonized to the
millisecond and the samples come in batches. 

This produces inaccuracy in the calculations. I'll attach a patch to correct
this behavior. Taking the min of samples startTime and the max of the samples
endTime
Comment 1 Rub 2006-10-18 13:10:48 UTC
Created attachment 19027 [details]
Calculator.java patch to take min and max of startTimes and endTimes into account

Changes the way SummaryReport calculates the thoughput taking into account the
min and max of startTimes and endTimes. Previous version relies on samples
coming in order to accurately make the calculations. This assumption is false
in distributed testing (very false in batch mode!)
Comment 2 Sebb 2006-10-20 16:35:39 UTC
Thanks.

The code in SVN branch 2.2 has been fixed, and is in the nightly build:

2-2.20061020