Sorry for long posts. I think we hit just a tip of the iceberg. >From my experience, the most important problem of timers is "timers are listeners, not samplers". Users assume that timers are executed at the place where they appear in test plan. It takes a while to realize that timers are inherited to all the siblings' child samplers.
Not sure how to fix that though. Some warning should probably be displayed if a timer has more than one siblings' child (~ "the timer is probably misplaced"). > There is no reasons not to scale I mean not "performance-wise" scalability, but code maintenance/user-experience scalability. The question is what efforts will consume the approach of making timers more complex. > Synchronizing timers will be pre-sample always Well, there might be an interesting pattern to synchronize in post-sample, so questions might appear "why my timer does not support pre-post mode". >Timer either pre-sample or post-sample, there is no "mid-sample" timers. I mean orthogonal features as well. There might be "pre _and_ post" delays at the same time. For instance, I want "test reproducibility" feature. So I could replay the same delays in different test executions (that is using some pre-defined random seed). I have that feature in my own timer and it proved to be very useful to compare different test executions. If the same feature appears in public build, there is a question how "random seed" should be specified for timers in a consistent way. >The behavior will be consistent and timer will be called after post-processor I mean another kind of consistency: 1) Currently JMeter has separate sets of "pre processors" and "post processors". You can't pick "mode of processor" in the processor's UI. 2) For timers you suggest a bit different approach: single timer while pre-post mode to be configured in the UI. That is what I call inconsistent user experience. > Subtracting sleep time from total transaction time is a > question for Transaction Controller and out of scope for this topic It should be in scope. Did you verify that your approach does not breaks TC logic? You shouldn't deliver a feature that does not play well with basic functionality like TC. Otherwise users would be very confused. Vladimir
