Hi My answers inline below
2016-08-31 1:11 GMT+02:00 harry_no_spot <[email protected]>: > In my opinion. in LR it's a goodlooking feature but not a very userfu > feature. > All the Loadrunner experts I know (inluding me) use this feature in LoadRunner > This feathure has no big use in practise. > Like I have said previously before, you record your script with think time and if you are not ok with recorder think time, you can overide it with this feature > The only use I think is to distritube the pressure. but Jmeter has > Throughtput controller, can control the throughtput distribution accurately. > Loadrunner have it too (called pacing in Loadrunner) and the two features are used > > > 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 > >> >
