Hi, @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 LoadRunner 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 http://loadrunnertips.com/img/img_130630941356514774.png Antonio 2016-08-19 14:21 GMT+02:00 Vladimir Sitnikov <[email protected]>: > >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 >
