jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <>
Subject Re: Post-Sampler Timers
Date Thu, 16 Apr 2015 09:31:34 GMT
Andrey>why people search for problems instead of opportunities :)
Andrey>Any thoughts/objections on this?

Well, it was you who wanted objections.

In two words: I agree with Shmuel, I do not see much value.
See in the end of the mail my vision on how the need for post-samplers
can be fixed.

>> Users assume that timers are executed at the place where they appear
>> in test plan.
> This is common problem with all JMeter components, like config items and
> post-processors. I have nothing to do with this.

We all should care not to make the UI and the core an inconsistent
combination of features here and there.

> So you can add two timers, one for pre-sample and one for post-sample.

And there it goes. I wonder how often "post-sample" timer is actually required.
I agree the optimization (i.e. optimize user clicks in UI to produce
the jmx) should be for the most common case, however I can't tell if
current workarounds of "adding timer to the next sampler" or "adding
dummy sampler with timer" are much worse than incompatibility of jmx
plans we'd get with post timers.

Test plan with post timers would require a specific JMeter version,
thus it may produce catch 22: "you want to downgrade JMeter to avoid
some bug, but you can't since old JMeter does not load your jmx".

Let me try a bit different view:
Currently you tie low level representation (particular samplers,
timers) with the UI.
In other words, you do not like "adding dummy test action" just
because it is messy in the UI. Is it the only reason?

What if JMeter UI could display higher level concepts, while still
using simple and dumb test actions/timers behind the scenes?
That would allow nice UI and backward-and-forward-compatible jmx
format while keeping core test plan elements simple. Think of java
source vs java byte code.

For instance, in the particular case JMeter UI could display the timer
in question as "post timer" somehow, and when it comes to store that
plan in jmx, JMeter would convert "post timer" to a dummy test action
with a sampler inside.
The core is happy to execute the plan unmodified, while you get "nice UI".

This scales as proven by java language evolution when new language
features are smoothly integrated with old binaries.

As a first step, "macros" can be implemented.
For instance, you click "add think timer" and JMeter adds "Test
Action"+"Think Timer" in a single shot.
I think it would cover most of the current needs, while keeping jmx
and core compatible.

Later we can teach the UI to fold-unfold macros.


View raw message