1
votes

I have set the number of threads and ramp-up time to 1/1 and I am iterating my 1000 records from data.csv for 1800 seconds. Now given the numbers, I have set the CTT, constant time throughput to 2000 every minute and I expected the average throughput to be 2000/60 = 33.3/sec, but I get 18.7/sec, when I increased the throughput to 4000/60, I still get 18 or 19/sec.

enter image description here

enter image description here

2
To gain enough throughput, CTT needs enough threads. Try to increase the thread.Adnan
what is the ideal value in my case, I have set thread/rampup to 1000/0 and the avg throughput is like 70/sec, 30/sec, 29/sec etc..zillani
Thread 1000 is way too much I presume. Use as much as you need. Maybe ~100 would be enough for to reach the throughput 33.3/sec as u mentioned. And try not to use the ramp up time as 0.Adnan
I have now set this to 100/6 and CTT to 4000/min and avg throughput is like 13.5/s, 6/s, 7.3/s whereas I expect this to improve, I don't understand the relation b/w threads/sec and CTT, I thought CTT would override the threads/sec numberzillani

2 Answers

3
votes

Constant Throughput Timer cannot force threads to execute faster, it can only pause threads to limit JMeter's throughput to the defined value.

Each JMeter thread executes samplers as fast as it can, however next iteration won't start until previous is finished so given you use 1 thread - the throughput won't be higher than application response time.

Also be aware that Constant Throughput Timer is accurate enough on minute level so you can rather manipulate "requests per minute" rather than "requests per second", if your test is shorter than 1 minute - consider using Throughput Shaping Timer

So I would recommend increasing the number of virtual users to i.e. 50.

See How to use JMeter's Constant Throughput Timer for more details.

2
votes

I guess your application average response time is around 50ms. Which means a single thread can only perform about 20 hits/sec (1 sec / 0.05 sec per hit = 20 hits/sec).

You have 2 solutions:

  • increase the number of threads to parallelize requests sent,
  • or make you app response faster (obviously harder).

At some point, when you application can't handle more load, you should see the hits/sec dropping and the average response time increase.

The graph below shows you an example of application which has a steady response time with up to 20 concurrent threads.

Sample graph showing response time and hits