Some time ago I did suggest to implement throughput timer that generates
JMeter thread reference:
JMeter plugins thread reference:
At that time the suggestion was declined and the timer was implemented
There was interest in merging that kind of timer to JMeter core, so I did
check if I could contribute it.
The result is positive, so it's time to negotiate the procedure.
To make long story short: the timer enables to generate Poisson arrivals
with constant throughput in a range of 0..3600 requests/hour (I'm not sure
what is the upper bound exactly, however it does exist)
The typical use case is "generate 100 orders per hour". For example, if
configured with 100/hour, the timer ensures that there are exactly 100
transactions each hour while the transactions are still launched at random
So I've two generic questions:
1) Go/no-go for inclusion? Please, some +1/-1 here.
2) How the timer should be named?
We used to name it as "Exponential Timer", however I do not find that name
to be understandable by regular end-user.
"Exponential Timer" was used just because "Poisson process has exponential
distribution of inter-arrival delays". So "exponential" in the name is 100%
scientifically correct, yet it is 100% protected from being understood by a
regular end-user. On the good side, it will produce good "Google results"
as the name is somewhat unique.
Theoretically, we could even drop "Poisson timer", and rework current
"Constant throughput timer" to use new algorithm, however that might be a
little bit too invasive.
I'm open to further discussion/questions/suggestions.
Technically speaking, the timer always coordinates all the threads in the
group and it creates "launch schedule" even before the first thread
arrives. Then the timer releases threads at pre-scheduled time by returning
proper "delay" value. The timer does not care when the thread was created.
It only cares on the exact timestamp the subsequent sample should take