jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Pokhilko <a...@ya.ru>
Subject Re: Post-Sampler Timers
Date Thu, 16 Apr 2015 07:21:06 GMT
My comments are below. I wonder why I hear so many objections, why
people search for problems instead of opportunities :)

Andrey Pokhilko

On 04/15/2015 08:04 PM, Vladimir Sitnikov wrote:
> 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").
This is common problem with all JMeter components, like config items and
post-processors. I have nothing to do with this.
>> 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".
No problem, we can add toggle to any timer.
>> 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.
So you can add two timers, one for pre-sample and one for post-sample.
Makes sense to manage these timers separately, since they reflect delays
of different nature.
> 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.
Good point, but I don't think this toggle worth introducing whole new
class of components. Pre/Post processors have different objects they
manipulate (next sampler and last sample result). Timers have no
difference except moment of their call. And duplicating all timers in
two groups looks not graceful idea.
>> 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