Bug 44374 - Constant Throughtput Timer Granularity is too coarse
Summary: Constant Throughtput Timer Granularity is too coarse
Status: RESOLVED FIXED
Alias: None
Product: JMeter - Now in Github
Classification: Unclassified
Component: Main (show other bugs)
Version: 2.3.1
Hardware: Sun Solaris
: P2 normal (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-07 07:47 UTC by Vladimir Soloshenko
Modified: 2008-03-01 17:41 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Soloshenko 2008-02-07 07:47:05 UTC
Trying to run test with constant throughput higher than 60000 executions per
minute leads to uncontrolled throughtput increase. It happens because of
millisecond level of delay granularity and due to usage of
System.currentTimeMillis() calls for delay calculations. Because in one minute
there are only 60 000 milliseconds and due to integer arithmetics for delay
calculation, delay() method always returns 0 if throughput is greater than 60000
samples per minute. However, nowadays it is not unusual to have tens of millions
executions per hour on SMP systems. I am testing Telecommunication platform
which intended to handle 50-60 milllions calls per hour.
Comment 1 Sebb 2008-02-07 07:54:54 UTC
But can a single JMeter instance approach 60 thousand transactions per second?

I very much doubt it, so it seems to me that there is no point in allowing for this.
Comment 2 Vladimir Soloshenko 2008-02-07 08:10:33 UTC
(In reply to comment #1)
> But can a single JMeter instance approach 60 thousand transactions per second?
> 
> I very much doubt it, so it seems to me that there is no point in allowing for
this.

The problem is that all calculations are done on PER MINUTE basis. Here the code:
long msPerRequest = (long) (MILLISEC_PER_MIN / getThroughput());
where MILLISEC_PER_MIN is a constant and equals to 60000. If getThroughput()
returns the value greater than 60000 the result will be 0. And throughput is
defined on PER MINUTE basis. Thus we can talk about 1000 executions per second
ONLY, NOT about 60000 per second.

May be Java 1.5 method: System.nanoTime() could help to solve this problem?
Comment 3 Vladimir Soloshenko 2008-02-07 08:24:04 UTC
At least, the following statement is wrong (IMHO):

long msPerRequest = (long) (MILLISEC_PER_MIN / getThroughput());

the result shoud be of floating point type (i.e. double), NOT integer (long) and
ONLY after in subsequent calculations like:

delay = JMeterContextService.getNumberOfThreads() * msPerRequest;

it is OK to cast floating point result to cast to integer (of long type).
Otherwise, all the requested throughputs more than 60000 will result to  zero
dalay for every interation. But 60000 samples per minute not to much, especially
if you configure this throughput for all threads!

Comment 4 Sebb 2008-03-01 17:41:56 UTC
Thanks for the suggestion, I've changed the calculation to use double.

The updated test suite shows that larger throughputs are now supported with more threads.

Change was committed to SVN in r632690.
Comment 5 The ASF infrastructure team 2022-09-24 20:37:41 UTC
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2068