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