Search code examples
jmeterjmeter-pluginsjmeter-5.0jmeter-4.0

Limitations in achieving a target JMeter throughput value

I want to understand the actual JMeter throughput behavior achieved at runtime.

Scenario - I'm increasing the JMeter throughput at runtime using Constant Throughput Timer and beanshell script as described here - https://www.blazemeter.com/blog/how-to-change-jmeters-load-during-runtime.

Test plan - Along with CTT as described above, simple threadgroup with fixed #threads and infinite loop iterations is configured. HTTP Sampler for GET call is used. No other timer or plugin is added in the test plan.

As I keep on increasing the target throughput of JMeter at runtime, I noted that the actual achieved throughput value is limited by mainly 2 factors -

  1. The threads in my thread group.
  2. The performance bottleneck of target app.

I have questions regarding both the limitations -

  1. Once the highest throughput is achieved using all threads in current threadgroup (assuming there're no errors from the target app yet), is there a way to increase the #threads at this point dynamically at runtime to achieve a higher JMeter throughput?

  2. Now as I keep on increasing JMeter throughput, it can't be increased further due to errors from the target app. How does the JMeter identify performance bottleneck of my target app and react to it? Does it add any delay or kill threads or apply any such mechanism to reduce it's throughput to the max that the target app can sustain?

  3. In continuation with point #2, if JMeter identifies and reacts to the performance bottleneck by any method, what are the factors (like error rate, response latency etc.) that control it's throughput to keep it within the max limit of the target app? Are these factors configurable or extensible?

Solution

    1. You can play the same trick with the number of threads in the thread group, just define it using __P() function and you will be able to manipulate it using Beanshell server. Another option is using a JSR223 Test Element and Groovy language to add the new thread(s) where/when required like:

      ctx.getThreadGroup().addNewThread(0, ctx.getEngine())

    2. JMeter doesn't "identify" anything, it just tries to execute Samplers as fast as it can and the number of requests per second depends on 2 factors:

      • your application needs to be able to respond fast enough
      • JMeter itself needs to be able to send requests fast enough, i.e. you need to follow JMeter Best Practices

      there are no "mechanisms" which detect the application under test behaviour, the closest solution is Auto Stop Listener

    3. See point 2