jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <sitnikov.vladi...@gmail.com>
Subject Re: Post-Sampler Timers
Date Wed, 15 Apr 2015 17:04:17 GMT
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

Mime
View raw message