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.
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.
(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?
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!
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.
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2068