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
