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" <[email protected]> wrote: >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 >>
