jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gomes Rodrigues <ra0...@gmail.com>
Subject Re: Re: Thoughts on 2 proposals
Date Wed, 31 Aug 2016 07:51:55 GMT
Hi

My answers inline below

2016-08-31 1:11 GMT+02:00 harry_no_spot <13651877684@163.com>:

> 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" <ra0077@gmail.com>
> 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 <sitnikov.vladimir@gmail.com
> >:
> >
> >> >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
> >>
>

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