Hi, The concept is simple enough and interesting. But I think you can already achieve what you're asking for.
Why would it be needed in the case of random timers? Let's say you have cycle timer, and you go for a random period. Isn't the period added by the cycletime minus existing thinktime covered in the deviation? If I'd want to simulate what a single user does in a cycle, and the response times of the app get in my way, I'd just adjust the offset and the deviation, at the moment and I obtain random cycle times in the same range as if I could achieve if I had the cycle timer option. It would add extra calculation and little benefit. I fail to understand why its needed, but would support the idea, because a lot of people struggle to understand how JMeter generates its throughput, why v-users's actions get out of sync after the first few thread loops. With a cycle time, it would be easier to synchronise threads if its really needed. But its not a usecase that should be recommendable. This is how I understand your request (an example of why I think the functionality is available in a different form), please correct me if my understanding is wrong: If resp times degrade over time (justifiable by new features added), you wouldn't have to adjust test scripts, with the cycle timer option, you'd get the same amount of actions that you would have expected when you first designed the test. This is one case where I would like such control of a single threads throughput. But we do have something similar at the moment, I use the Constant Throughput Timer for this, with the per thread option. Is this not enough? Cheers, Adrian Speteanu On Tue, Jul 9, 2013 at 7:40 PM, Fabian Brosig <fabro...@gmail.com> wrote: > Hi, > > In my JMeter script, I wanted to configure a timer with an exponential > distributed delay. > However, using the Poisson timer, I could configure only the think time, > not the cycle time. (In short: cycleTime = responseTime + thinkTime) > > Here is a more detailed explanation, what "Cycle Time" is, and why it is > useful in load testing scenarios... (citation from > http://www.testnscale.com/docs/CycleTimesTutorial.html) > "Cycle Time in Faban refers to the inter-arrival time between subsequent > requests that arrive at a server. For internet-based applications where the > user population is unknown, it makes sense to model cycle times (rather > than think times). Note that there is a subtle difference between using > think times and cycle times. In a load test that uses think times, if the > server slows down and response times increase, the think times are still > generated in the same manner giving the server time to recover. But in a > test that uses cycle times, if the response time is large, the cycle time > still remains the same - the emulated user simply sleeps for a shorter time > between requests (and in the worst case where the response time is larger > than the cycle time, will not sleep at all) causing the load on the server > to increase. This will quickly result in excessive load on the server > causing increasingly larger response times. This is not necessarily a bad > thing - it can pin-point scalability problems in the server more quickly > and help you fix them." > > If I want to achieve a certain throughput level, configuring the ThinkTime > is not useful, since the actual throughput depends on the response times. I > now implemented an own PoissonTimer that times the cycle time, not the > think time. > (The implementation extends the standard PoissonTimer, and uses code > fragments of the ConstantThroughputTimer.) > > My question: > From my point of view, it would be definitely useful to provide at least > all RandomTimers with an option "control think time or cycle time?". The > implementation is rather straight-forward, and I really would like to help > with that. What do you think? > > Note: Using the constant throughput timer is not an option, because the > cycle times are then constant (see implementation of > ConstantThroughputTimer), which is not really realistic/representative. > > Kind Regards, > Fabian >
