jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <>
Subject Re: Throughput timer that generates Poisson process
Date Tue, 20 Sep 2016 14:46:31 GMT
Hello Vladimir,

On Tue, Sep 20, 2016 at 4:36 PM, Vladimir Sitnikov <> wrote:

> Hi,
> Some time ago I did suggest to implement throughput timer that generates
> Poisson process.
> JMeter thread reference:
> JMeter plugins thread reference:
> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message