jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Pokhilko <>
Subject Re: Post-Sampler Timers
Date Wed, 15 Apr 2015 15:22:01 GMT
There is no reasons not to scale. The behavior will be consistent and
timer will be called after post-processor, allowing to set some variable
based on sample result and use that variable as think-time delay.

Not each of the timers would need to support the toggle (e.g. Constant
Throughput and Synchronizing timers will be pre-sample always), and by
default any timer would be "pre-sample" to be compatible with previous
versions of JMeter scripts.

I see no "next" feature that will lead to exponential growth of logic.
Timer either pre-sample or post-sample, there is no "mid-sample"
timers... Again, for each timer we can decide if it will offer UI to
change its role or not.

Timer will not affect sampler time unless used within Transaction
controller, so this aspect will also be consistent with current
behavior. Subtracting sleep time from total transaction time is a
question for Transaction Controller and out of scope for this topic.

Andrey Pokhilko

On 04/15/2015 05:54 PM, Vladimir Sitnikov wrote:
>> 3. Modify timers UIs where it is reasonable, adding radio button to
>     change timer mode
> Will that scale?
> Will that be consistent with pre/post processors?
> Each and every timer would have to support "pre-post mode".
> Suppose you add another feature, then it will be an exponential number
> of combinations in timer UIs.
> Well, there could probably be "post timer" that has access to the
> sampler result and adjust sleep duration accordingly (e.g. sleep 1sec
> for each 10KiB or response).
> I wonder if "seeping after sampler execution" would break response
> time reporting.
> Especially, for "transaction controller" that is known to have obscure code.
> Vladimir

View raw message