You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by bu...@apache.org on 2010/03/11 10:49:37 UTC
DO NOT REPLY [Bug 48889] New: Wrong response time with
mode=Statistical and num_sample_threshold > 1
https://issues.apache.org/bugzilla/show_bug.cgi?id=48889
Summary: Wrong response time with mode=Statistical and
num_sample_threshold > 1
Product: JMeter
Version: 2.3.4
Platform: PC
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: Main
AssignedTo: jmeter-dev@jakarta.apache.org
ReportedBy: j.kalsbach@jk-itberatung.de
I’ve got a master-slave setup and need to do statistical sampling because
otherwise the master dies on OutOfMemory. I use an Aggregate Graph/Report as
recommended. The calculated values for hits/sec reported by the listeners are
wrong.
To analyze the situation use I the following testplan:
- Threadgroup with 10 threads running for 100 iterations
- BeanShell Sampler sleeping for 500 millis
- AggregateGraph/Report
Now the results must be more or like:
- Hits/sec just below 20 (like 19.6)
- Average response time approx 500 millis
Local execution delivers this result.
Set num_sample_threshold=1 and time_threshold=3600 delivers this result.
Set num_sample_threshold=100 time_threshold=3600 delivers
- Hits/sec 19.7
- Average response time 56!
The response time varies with the sample_threshold but always is way to low.
The higher the sample_threshold the higher the delta between real and reported
response time
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 48889] Wrong response time with mode=Statistical
and num_sample_threshold > 1
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48889
Sebb <se...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #4 from Sebb <se...@apache.org> 2010-03-11 23:40:11 UTC ---
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
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 48889] Wrong response time with mode=Statistical
and num_sample_threshold > 1
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48889
--- Comment #3 from JottKa <j....@jk-itberatung.de> 2010-03-11 15:55:35 UTC ---
(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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 48889] Wrong response time with mode=Statistical
and num_sample_threshold > 1
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48889
--- Comment #2 from Sebb <se...@apache.org> 2010-03-11 14:58:30 UTC ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 48889] Wrong response time with mode=Statistical
and num_sample_threshold > 1
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48889
--- Comment #1 from JottKa <j....@jk-itberatung.de> 2010-03-11 12:57:40 UTC ---
Created an attachment (id=25115)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=25115)
proposed patch
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org