>Bug 60018 - Timer : Add a factor to apply on pauses
>How do you want to implement it ?
For instance:
* use ${clickThinkTime}, ${pageThinkTime} kind of variables
* use ${__javaScript...} to implement multiplication
Can you please elaborate why do you need to "multiply durations by a given
factor"?
I does not seem right if you mean "you record test scenario at strict 2x
rate". Are you sure the multiplication factor should be constant?
The only case I can imagine is "multiply all durations by 0.000001 to make
them effectively a no-op". However, that is already implemented via "run
without delays" mode or so.
ULP>Note that in my experience of every campaign, it is always difficult if
impossible to have realistic Think time provided by customers so it's a
matter of change and test.
Can you put more details how do you identify "what is the right
multiplication factor"?
Suppose the "multiply timers by X" was integrated.
Suppose you've created a test plan.
How do you tell if the X should be 0.5 or 2.0 or whatever?
Vladimir>-0. It is not clear what is the gain, however if implemented the
feature would basically double the set of required distributed tests:
nullify=true, and nullify=false.
ULP>I don't understand what you are writing. Where this is doubled ?
Technically speaking, when new "mode" is introduced to a software system,
users expect that the system would behave "well" in BOTH modes.
So, if we add "nullifyComment" property, then :
1) We would have to test each release with BOTH of those modes. That
literally means running each test twice (at least distributed ones).
2) We would have to think how that feature integrates with other features.
For instance, if storage format changes, we would have to pay attention to
support the "nullify" feature.
Even though adding "if (!nullifyComment)" looks simple, making sure full
regression suite is run in both modes, and supporting that additional mode
might be much more complicated.
ULP>Note besides of that that the Timer approach in JMeter is far from
simple
ULP>- TestAction (sleep = 0)
ULP> |-------Timer as a child
Once upon a time we've discussed "macro node" feature.
Basically, JMeter UI don't have to be a one-to-one match of the test plan.
For instance, JMeter UI might understand "TestAction/Timer" pattern, and
show that via single node in the tree.
So it would simplify the particular use-case (I would admit it is an often
one), while keeping executor logic untouched.
Vladimir
