Requirement:
- Hourly active user expectation (per hour): 350
- TPS expectation: 18
- App domain: reading platform (low number of transactions, but high – active user count)
Thread group setup:
- No of endpoints: 100 +
- Threads:350
- constant throughput timer target throughput value: 1080 samples per minute (enabled – all active threads in current thread group shared option)
- think time: flow action controller added with 5-15s variations
- loop – infinite
- duration – 3600s
- ramp up: 600s
- same user on each iteration – unchecked
Actual results:
When Constant throughput timer applied, the execution does not fully execute all endpoints of the thread group. generated summary report only contains the first initial set of endpoints only, by changing the CTT and thread numbers, the number of executed endpoints is changing.
why JMeter executions behave like this with low TPS but with high number of threads? Does JMeter kill threads halfway to match the expected TPS levels? if yes, how can we execute all of the endpoints under this controlled setup?
Since we need to simulate the expected number of users, as well as the expected TPS levels to get a realistic result, how can we achieve this? Appreciate your Help on this!
JMeter executes Samplers upside down (or according to Logic Controllers)
If some Samplers are not getting executed it might mean that either they too low in the queue or test duration is too short or something unexpected happened.
JMeter won’t “kill threads halfway” on its own, but it might be the case there is a problem with your test or JMeter setup, take a look at jmeter.log file, normally it should contain the reason of thread stopping or termination.
Also I don’t think you need “think time”, the Constant Throughput Timer will automatically pause the threads to maintain the target throughput. However it will not kick off extra threads if current amount is not sufficient so you might want to consider switching to Throughput Shaping Timer or Precise Throughput Timer