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 > -- Cordialement. Philippe Mouawad.
