jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gomes Rodrigues <>
Subject Re: Thoughts on 2 proposals
Date Tue, 30 Aug 2016 15:24:32 GMT

@Vladimir: Sorry my question about implementation was to UBIK LOAD PACK
Support and not you

In my opinion, this feature could be usefull.

It will allow gain productivity in this case

I record a script with think time by using proxy recorder
In I am not happy with think time recorded, I can use this feature without
to have to modify all the think time

It allow to "split" think time in the script and think time played like in

In Loadrunner we have :
ignore think time
replay think time
as recorded
multiply by X
Use random percentage of recording think time
limit think time to X

We can see it in


2016-08-19 14:21 GMT+02:00 Vladimir Sitnikov <>:

> >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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message