Hello Vladimir,

On Tue, Sep 20, 2016 at 4:36 PM, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Hi,
> Some time ago I did suggest to implement throughput timer that generates
> Poisson process.
> JMeter thread reference:
> http://mail-archives.apache.org/mod_mbox/jmeter-dev/201502.mbox/%3CCAB=Je-
> GON1QUxAD6nnzMLA0wh9JMpk8nh=y8uylihfg8mao...@mail.gmail.com%3E
> JMeter plugins thread reference:
> https://groups.google.com/d/msg/jmeter-plugins/K8I6LIRwYjM/kWteXor28kQJ
> At that time the suggestion was declined and the timer was implemented
> in-house.
> 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.
Great news.

> 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
> timestamps.
> So I've two generic questions:
> 1) Go/no-go for inclusion? Please, some +1/-1 here.
Is it possible to see the code before voting ?
+1 for the theorical proposal but I would need to see the implementation.

> 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
> place.
> Vladimir

Philippe Mouawad.

Reply via email to