jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From harry_no_spot <>
Subject Re:Re: Thoughts on 2 proposals
Date Tue, 30 Aug 2016 23:11:59 GMT
In my opinion. in LR it's a goodlooking feature but not a very userfu feature.
This feathure has no big use in practise.
The only use I think is to distritube the pressure. but Jmeter has Throughtput controller,
can control the throughtput distribution accurately.

At 2016-08-30 23:24:32, "Antonio Gomes Rodrigues" <> wrote:
>@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