jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gomes Rodrigues <>
Subject Re: Throughput timer that generates Poisson process
Date Tue, 20 Sep 2016 15:14:57 GMT
Hi Vladimir,

2016-09-20 16:36 GMT+02:00 Vladimir Sitnikov <>:

> 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.
> 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)
How to find this limit?
3600 requests/hour is not very high :-(

> 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.
Like "Constant throughput timer" but more accurate?

> So I've two generic questions:
> 1) Go/no-go for inclusion? Please, some +1/-1 here.
It will depend on the upper bound

I think it will be great to have a more accurate "Constant throughput
timer" in JMeter but if there is too much limitation, I think it will be
better to integrate it in another way

In "Constant throughput timer", have a check box "accurate but limited to
XXX requests/hour" which switch from classic algorithm to your algorithm

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

If the limit of requests/hour is not too low, I think it's the best
solution or have a checkbox to switch between the two algorithm

> 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

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