Summary: | Wrong response time with mode=Statistical and num_sample_threshold > 1 | ||
---|---|---|---|
Product: | JMeter - Now in Github | Reporter: | JottKa <j.kalsbach> |
Component: | Main | Assignee: | JMeter issues mailing list <issues> |
Status: | RESOLVED FIXED | ||
Severity: | major | ||
Priority: | P2 | ||
Version: | 2.3.4 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All | ||
Attachments: | proposed patch |
Description
JottKa
2010-03-11 09:49:36 UTC
Created attachment 25115 [details]
proposed patch
Thanks for the suggested patch, which should help. However, I think the threadGroup is still needed, otherwise unrelated threads in different thread groups will be aggregated, leading to the same problem. (In reply to comment #2) > Thanks for the suggested patch, which should help. > > However, I think the threadGroup is still needed, otherwise unrelated threads > in different thread groups will be aggregated, leading to the same problem. Yes but at least with the current implementation the event.getResult().getThreadName() call already contains the threadGroup name. A typical key would be "NameOfSampler-NameOfThreadGroup 1-10". I just verified the proper working with two threadgroups. But an explicit call to getThreadGroup would make it more robust. Turns out that the problem was not really due to aggregating across thread groups. The StatisticalSampleResult now maintains the elapsed time directly, rather than trying to fake it by setting the start and end times. See: URL: http://svn.apache.org/viewvc?rev=922072&view=rev Log: Bug 48889 - Wrong response time with mode=Statistical and num_sample_threshold > 1 See also SVN revisions: 922069,922067,922055,922054,922051 This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2352 |