Partial fix for Throughput Shaping Timer#558
Partial fix for Throughput Shaping Timer#558pbaykalov wants to merge 2 commits intoundera:masterfrom
Conversation
if rps is less than 1 and if delay() is executed inside new second this condition will evaluate to false and cause double-release potentially this can cause very long series of 1 RPS release if resonance is hit: if ((total time for each sample to execute with all other thread actions) + msecPerReq ) % 1000 is close to 0 or 1000 then 1 RPS will fire for very long time for arbitrarily small RPS this commit fixes this multiple release for small RPS but there are still problems if the requests are long enough I will suggest better and simplier code in future commits
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #558 +/- ##
=========================================
Coverage 68.94% 68.95%
Complexity 2574 2574
=========================================
Files 230 230
Lines 15609 15609
Branches 1589 1589
=========================================
+ Hits 10762 10763 +1
+ Misses 4057 4055 -2
- Partials 790 791 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
What's the main reason for |
It's the default branch, in case we're not delivering enough hits. The meaning of |
It's not "default" it's the only return statement in |
Ok, maybe we're talking about different places in code. Can you point to exact file and line that you're talking about? |
Ok, I see what you mean. So, the meaning of it is we tell JMeter that there should be no delay at all on its side, since our code has already did introduce the required delay with |
This PR partially fixes erratic behaviour of Throughput Shaping Timer with low requested intensity.
This is the problem:

TST_MCVE.zip
Actual intensity might strongly depend on what exactly the requested intensity is and how many threads there are.
The timer is still not guaranteed to work correctly in specific but realistic situaitons.