Jmeter - Difference between thread group and loop controller in terms of performance
I am new to Jmeter. Here's one thing that puzzles me
There are two scenarios I am testing for calculating performance numbers using Jmeter
- Having 1 set of threadgroups with the number of loops set to 50 and having one https sampler.
- Having 1 thread group with a loop count as only 1, but instead using a loop controller with a loop count set to 50. In this case, my https sampler is inside the loop.
In both cases, the https sampler is executed 50 times, but I notice a big difference in performance.
For 1 - 100 ms ( Average of 50 calls)
For 2 - 30 ms ( Average of 50 calls)
The question is why I see this difference. Ideally, both scripts should give the same performance number. Also to add in Jmeter settings I have "Use keep alive" as off and also https.use.cached.ssl.context is set to false in jmeter.properties.
source to share
What is your parameter Ramp-up
for a scenario where 50 loops are defined at the topic group level? By documentation
The ramp-up period tells JMeter how long it will take to "ramp up" to the full number of selected threads. If 10 threads are used and the ramp period is 100 seconds, then JMeter will take 100 seconds to get all 10 threads up and down. Each stream will start 10 (100/10) seconds after the start of the previous stream. If there are 30 threads and a 120 second rise period, then each subsequent thread will be delayed by 4 seconds.
Ramp up by default 1
. If you are looking for the same behavior for Thread Group and Loop Controller, you need to set it to 0
.
Going forward sending requests as fast as JMeter can is not what you might call a real life scenario. Real users do not clog this or that endpoint, they need some time to "think" before doing the next action. This "time of thought" can be modeled using, for example, the "Constant timer" . However, a smarter way to set your desired load is with a Constant Bandwidth Timer
source to share