JMeter thread groups not reaching specified transactions per second

1
votes

I’m running into an issue in JMeter 5.4.1 where my thread groups aren’t reaching the specified transactions per second.

I have two thread groups in a single JMeter test that run in parallel. Each thread group is making a single API call. The first thread group has 300 threads allocated to it and has a constant throughput timer with the target throughput of 45,000 samples per minute, which ends up being 750 transactions per second. The second thread group has 100 threads allocated to it and has a constant throughput timer with the target throughput of 9,000 samples per minute, which ends up being 150 transactions per second.

After running several tests, both thread groups never reach their target throughput. The first thread group hits about 300 transactions per second and the second thread group hits about 100 transactions per second. The average response time for the first thread group is 5 ms and the average response time for the second thread group is 8 ms. This leads me to believe that the service while testing is keeping up fine, but the JMeter machine isn’t.

The curious part is that running these thread groups in parallel on a single JMeter instance causes the reduced transactions/second. We ran an experiment where we split the two thread groups to two difference instances of JMeter and ran them at the same time on the same machine. That allowed us to hit the correct transactions/second. This makes me believe that the machine can keep up, but there is something strange about JMeter when it runs these two threads in one JMeter instance. Any clues on why that is and how to fix it?

1
performancejmeterjmeter-5.0threadgroup

1 Answers

0
votes

  1. Constant Throughput Timer can only pause JMeter's threads to limit the throughput to the desired value, it won't kick off any extra threads if current amount is not sufficient to conduct the required load. The option capable of doing this is Concurrency Thread Group and Throughput Shaping Timer combination (please read the answer till the end before trying)

  2. Your application needs to respond fast enough, i.e. if you're trying to achieve 750 requests per second with 300 threads maximum response time needs to be less or equal to 400 ms, if it takes longer - the throughput will be proportionally lower.

  3. JMeter needs to be able to send requests fast enough, you cannot run it on a lousy laptop and expect that it will accomplish successful DoS attack against a distributed auto-scaling cluster so: