You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by UBIK LOAD PACK Support <su...@ubikloadpack.com> on 2016/08/18 20:11:20 UTC
Thoughts on 2 proposals
Hello,
We opened today 2 enhancement requests:
- https://bz.apache.org/bugzilla/show_bug.cgi?id=60018
- https://bz.apache.org/bugzilla/show_bug.cgi?id=60017
Would you be ok to integrate 2 patches if we implement what we proposed ?
Thank you
Regards
UbikLoadPack Team
@ubikloadpack
Re: Thoughts on 2 proposals
Posted by Antonio Gomes Rodrigues <ra...@gmail.com>.
Hi
In Loadrunner, the feature (if my remember are good) only modify the think
time of the lr_think_time() function used in the script
Antonio
2016-08-31 9:17 GMT+02:00 Vladimir Sitnikov <si...@gmail.com>:
> >As you read, the proposed solution (add a new field to timers) handles
> also
> the Ajax case.
>
> That is true.
> However it would likely to require user to walk over test plan and flip
> switches "adjust or not" manually. That's a pity.
>
> That would open one more pitfall of "blind timer adjustment would give
> unexpected results".
>
> Vladimir
>
Re: Thoughts on 2 proposals
Posted by Philippe Mouawad <ph...@gmail.com>.
Hi Vladimir,
As you can read I just tried to provide an answer to your question.
I don't think there was a patch right ?
You can see I asked for a bugzilla and an attached patch.
Anyway, please provide a patch so that we can review it.
I am very interested if it is a better solution than CTT.
Regards
On Wednesday, August 31, 2016, Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Philippe>Are you sure you submitted it to JMeter ?
>
> I am quite sure.
>
> Here's the thread:
> http://mail-archives.apache.org/mod_mbox/jmeter-dev/201502.mbox/%3CCAB=Je-
> GON1QUxAD6nnzMLA0wh9JMpk8nh=y8UyLiHFg8MAOv3g@mail.gmail.com%3E
>
> Here's your response
> http://mail-archives.apache.org/mod_mbox/jmeter-dev/
> 201502.mbox/%3CCAH9fUpZX=o6cpuinY-2CUmg8YT8Fo9Az76cpWC_
> E+T_YE0y5yQ@mail.gmail.com%3E
>
>
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
Re: Thoughts on 2 proposals
Posted by Vladimir Sitnikov <si...@gmail.com>.
Philippe>Are you sure you submitted it to JMeter ?
I am quite sure.
Here's the thread:
http://mail-archives.apache.org/mod_mbox/jmeter-dev/201502.mbox/%3CCAB=Je-GON1QUxAD6nnzMLA0wh9JMpk8nh=y8UyLiHFg8MAOv3g@mail.gmail.com%3E
Here's your response
http://mail-archives.apache.org/mod_mbox/jmeter-dev/201502.mbox/%3CCAH9fUpZX=o6cpuinY-2CUmg8YT8Fo9Az76cpWC_E+T_YE0y5yQ@mail.gmail.com%3E
Vladimir
Re: Thoughts on 2 proposals
Posted by Philippe Mouawad <ph...@gmail.com>.
Hi Andrei,
Existence of your plugins manager(which is a great idea that should have
been in Core) must not mean core Jmeter should not be enhanced.
Plugins can be of any quality, having features in core guarantees it.
Regards
On Wednesday, August 31, 2016, Andrey Pokhilko <ap...@ya.ru> wrote:
> That thread was one year ago. Today, there is Plugins Manager that
> allows you to maintain your plugin under your GitHub account and use
> Plugins Manager as a way to distribute your plugin for audience.
>
> Andrey Pokhilko
>
> On 08/31/2016 01:20 PM, Philippe Mouawad wrote:
> > On Wednesday, August 31, 2016, Vladimir Sitnikov <
> > sitnikov.vladimir@gmail.com <javascript:;>> wrote:
> >
> >> UBIK>because you mentioned in the bugzilla CTT
> >>
> >> I try to protect JMeter end-users from culprits like "when using adjust
> >> timers CTT produces completely wrong load rate". I do not suggest to
> >> discuss CTT drawbacks here.
> >>
> >> UBIK>CTT has use cases but does not fit here due to variable pauses I
> >> think.
> >>
> >> As far as I understand you message, CTT behaves bad even without "adjust
> >> timers" feature. If that is true, then it is just a CTT issue, and it
> is an
> >> off-topic for "adjust timers" thread.
> >>
> >> UBIK>Because it is probably impossible.
> >>
> >> Oh. I haven't touched the code of my exponential timer for more than two
> >> years. It just works and produces the desired load. So "timer that
> matches
> >> the configured throughput" is both possible, and usable by load test
> >> engineers.
> >>
> >> Unfortunately, the timer was rejected by both JMeter and JMeter plugins
> >> teams.
> >
> > Are you sure you submitted it to JMeter ?
> > I don't remember that .
> > Feel free to reconsider proposing it.
> >
> >
> >> JMeter thread:
> >> http://mail-archives.apache.org/mod_mbox/jmeter-dev/
> 201502.mbox/%3CCAB=Je-
> >> GON1QUxAD6nnzMLA0wh9JMpk8nh=y8UyLiHFg8MAOv3g@mail.gmail.com
> <javascript:;>%3E
> >>
> >>
> >> JMeter plugins thread:
> >> https://groups.google.com/d/msg/jmeter-plugins/K8I6LIRwYjM/kWteXor28kQJ
> >>
> >> Vladimir
> >>
> >
>
>
--
Cordialement.
Philippe Mouawad.
Re: Thoughts on 2 proposals
Posted by Vladimir Sitnikov <si...@gmail.com>.
Andrey>That thread was one year ago.
JMeterPlugins discussion
https://groups.google.com/forum/#!msg/jmeter-plugins/K8I6LIRwYjM/kWteXor28kQJ
took
place more than three years ago.
2013/04/04 to be exact.
Vladimir
Re: Thoughts on 2 proposals
Posted by Andrey Pokhilko <ap...@ya.ru>.
That thread was one year ago. Today, there is Plugins Manager that
allows you to maintain your plugin under your GitHub account and use
Plugins Manager as a way to distribute your plugin for audience.
Andrey Pokhilko
On 08/31/2016 01:20 PM, Philippe Mouawad wrote:
> On Wednesday, August 31, 2016, Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
>
>> UBIK>because you mentioned in the bugzilla CTT
>>
>> I try to protect JMeter end-users from culprits like "when using adjust
>> timers CTT produces completely wrong load rate". I do not suggest to
>> discuss CTT drawbacks here.
>>
>> UBIK>CTT has use cases but does not fit here due to variable pauses I
>> think.
>>
>> As far as I understand you message, CTT behaves bad even without "adjust
>> timers" feature. If that is true, then it is just a CTT issue, and it is an
>> off-topic for "adjust timers" thread.
>>
>> UBIK>Because it is probably impossible.
>>
>> Oh. I haven't touched the code of my exponential timer for more than two
>> years. It just works and produces the desired load. So "timer that matches
>> the configured throughput" is both possible, and usable by load test
>> engineers.
>>
>> Unfortunately, the timer was rejected by both JMeter and JMeter plugins
>> teams.
>
> Are you sure you submitted it to JMeter ?
> I don't remember that .
> Feel free to reconsider proposing it.
>
>
>> JMeter thread:
>> http://mail-archives.apache.org/mod_mbox/jmeter-dev/201502.mbox/%3CCAB=Je-
>> GON1QUxAD6nnzMLA0wh9JMpk8nh=y8UyLiHFg8MAOv3g@mail.gmail.com%3E
>>
>>
>> JMeter plugins thread:
>> https://groups.google.com/d/msg/jmeter-plugins/K8I6LIRwYjM/kWteXor28kQJ
>>
>> Vladimir
>>
>
Re: Thoughts on 2 proposals
Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
On Wednesday, August 31, 2016, Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> UBIK>because you mentioned in the bugzilla CTT
>
> I try to protect JMeter end-users from culprits like "when using adjust
> timers CTT produces completely wrong load rate". I do not suggest to
> discuss CTT drawbacks here.
>
> UBIK>CTT has use cases but does not fit here due to variable pauses I
> think.
>
> As far as I understand you message, CTT behaves bad even without "adjust
> timers" feature. If that is true, then it is just a CTT issue, and it is an
> off-topic for "adjust timers" thread.
>
> UBIK>Because it is probably impossible.
>
> Oh. I haven't touched the code of my exponential timer for more than two
> years. It just works and produces the desired load. So "timer that matches
> the configured throughput" is both possible, and usable by load test
> engineers.
>
> Unfortunately, the timer was rejected by both JMeter and JMeter plugins
> teams.
Are you sure you submitted it to JMeter ?
I don't remember that .
Feel free to reconsider proposing it.
> JMeter thread:
> http://mail-archives.apache.org/mod_mbox/jmeter-dev/201502.mbox/%3CCAB=Je-
> GON1QUxAD6nnzMLA0wh9JMpk8nh=y8UyLiHFg8MAOv3g@mail.gmail.com%3E
>
>
> JMeter plugins thread:
> https://groups.google.com/d/msg/jmeter-plugins/K8I6LIRwYjM/kWteXor28kQJ
>
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie
UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>
UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>
Re: Thoughts on 2 proposals
Posted by Vladimir Sitnikov <si...@gmail.com>.
UBIK>because you mentioned in the bugzilla CTT
I try to protect JMeter end-users from culprits like "when using adjust
timers CTT produces completely wrong load rate". I do not suggest to
discuss CTT drawbacks here.
UBIK>CTT has use cases but does not fit here due to variable pauses I think.
As far as I understand you message, CTT behaves bad even without "adjust
timers" feature. If that is true, then it is just a CTT issue, and it is an
off-topic for "adjust timers" thread.
UBIK>Because it is probably impossible.
Oh. I haven't touched the code of my exponential timer for more than two
years. It just works and produces the desired load. So "timer that matches
the configured throughput" is both possible, and usable by load test
engineers.
Unfortunately, the timer was rejected by both JMeter and JMeter plugins
teams.
JMeter thread:
http://mail-archives.apache.org/mod_mbox/jmeter-dev/201502.mbox/%3CCAB=Je-GON1QUxAD6nnzMLA0wh9JMpk8nh=y8UyLiHFg8MAOv3g@mail.gmail.com%3E
JMeter plugins thread:
https://groups.google.com/d/msg/jmeter-plugins/K8I6LIRwYjM/kWteXor28kQJ
Vladimir
Re: Thoughts on 2 proposals
Posted by UBIK LOAD PACK Support <su...@ubikloadpack.com>.
On Wed, Aug 31, 2016 at 10:04 AM, Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> UBIK>The issue with CTT is that it tries to match the throughput but always
> exceeds it before slowing down, and if CTT is combined with variable pauses
> UBIK>, it becomes very hard for CTT to adjust the pauses to reach the
> Throughput..
>
> If CTT has issues, why don't we just fix CTT then?
>
Because it is probably impossible.
CTT has use cases but does not fit here due to variable pauses I think.
That's why we need this additional feature.
> Do you mean CTT will never be able to follow given throughput goal?
>
It will but the more pauses are variable the harder it is for it.
> Well, the timer of my choice does follow given throughput with no
> overshooting/undershooting issues, so it is not that big deal to have a
> timer that just follows given throughput goal.
>
> Note: CTT is off-topic for the current thread.
>
No, because you mentioned in the bugzilla CTT as being able to answer this
use case. That's why I am mentionning it.
Note2: Philippe has recently fixed a couple of issues around CTT, thread
> pausing, etc.
>
Yes, but it only concerns the stopping of the test.
>
> Note3: I agree there might be valid cases for "adjust interpage timers"
> feature.
>
Good thing :-) We're almost okay then :-)
>
> Vladimir
>
--
Regards
Ubik Load Pack <http://ubikloadpack.com> Team
Follow us on Twitter <http://twitter.com/ubikloadpack>
Cordialement
L'équipe Ubik Load Pack <http://ubikloadpack.com>
Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
Re: Thoughts on 2 proposals
Posted by Vladimir Sitnikov <si...@gmail.com>.
UBIK>The issue with CTT is that it tries to match the throughput but always
exceeds it before slowing down, and if CTT is combined with variable pauses
UBIK>, it becomes very hard for CTT to adjust the pauses to reach the
Throughput..
If CTT has issues, why don't we just fix CTT then?
Do you mean CTT will never be able to follow given throughput goal?
Well, the timer of my choice does follow given throughput with no
overshooting/undershooting issues, so it is not that big deal to have a
timer that just follows given throughput goal.
Note: CTT is off-topic for the current thread.
Note2: Philippe has recently fixed a couple of issues around CTT, thread
pausing, etc.
Note3: I agree there might be valid cases for "adjust interpage timers"
feature.
Vladimir
Re: Thoughts on 2 proposals
Posted by UBIK LOAD PACK Support <su...@ubikloadpack.com>.
On Wed, Aug 31, 2016 at 9:17 AM, Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> >As you read, the proposed solution (add a new field to timers) handles
> also
> the Ajax case.
>
> That is true.
> However it would likely to require user to walk over test plan and flip
> switches "adjust or not" manually. That's a pity.
>
> If I look at the last 20 Plans created during our load test campaigns, it
would concern 5% of elements.
This feature is IMO needed whenever there is no precise information on
Think Times provided by the business through analytics and you have to
match an expected throughput.
Compared to CTT, it is also IMO an easier and more precise way to play on
throughput.
The issue with CTT is that it tries to match the throughput but always
exceeds it before slowing down, and if CTT is combined with variable pauses
, it becomes very hard for CTT to adjust the pauses to reach the
Throughput..
That would open one more pitfall of "blind timer adjustment would give
> unexpected results".
>
Do you have another idea ?
>
> Vladimir
>
--
Re: Thoughts on 2 proposals
Posted by Vladimir Sitnikov <si...@gmail.com>.
>As you read, the proposed solution (add a new field to timers) handles also
the Ajax case.
That is true.
However it would likely to require user to walk over test plan and flip
switches "adjust or not" manually. That's a pity.
That would open one more pitfall of "blind timer adjustment would give
unexpected results".
Vladimir
Re: Thoughts on 2 proposals
Posted by UBIK LOAD PACK Support <su...@ubikloadpack.com>.
On Wed, Aug 31, 2016 at 8:58 AM, Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> >Yes , but this case is already edgy in JMeter as there is no concept of
> parallel request
>
> Note:
> 1) page...ajax delay can be used even without parallel requests
> 2) I expect "parallel request" feature to be landed soon, so it makes sense
> to plan "adjust timers" feature accordingly. Don't you suggest that JMeter
> will miss parallel request feature forever, so we can just ignore that case
> when implementing "adjust timers"?
>
As you read, the proposed solution (add a new field to timers) handles also
the Ajax case.
Regarding Parallel request, I would also be happy to see it landing soon.
>
> Vladimir
>
--
Re: Thoughts on 2 proposals
Posted by Vladimir Sitnikov <si...@gmail.com>.
>Yes , but this case is already edgy in JMeter as there is no concept of
parallel request
Note:
1) page...ajax delay can be used even without parallel requests
2) I expect "parallel request" feature to be landed soon, so it makes sense
to plan "adjust timers" feature accordingly. Don't you suggest that JMeter
will miss parallel request feature forever, so we can just ignore that case
when implementing "adjust timers"?
Vladimir
Re: Thoughts on 2 proposals
Posted by UBIK LOAD PACK Support <su...@ubikloadpack.com>.
Hi all,
Some answers inline below.
Regards
On Wednesday, August 31, 2016, Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> >In my opinion, this feature could be usefull.
>
> TL;DR: I don't try to prove that the feature is bad. I just don't have
> motivation to implement this particular feature, so I list several corner
> cases when the feature can behave unexpectedly if implemented in a naive
> way.
>
>
> Let me take a step back.
>
> Here are some corner cases when "adjust timers" feature might harm:
>
> 1) Throughput timers. If a timer is set to maintain X requests per second,
> then "adjust timers" feature should not adjust that timer. Otherwise the
> throughput would be way off.
> There is at least one such timer in JMeter core.
True.
as explained in bugzilla, this will be handled through a method
canTimerBeAdjusted.
CTT and Sync Timer will return false.
> 2) Suppose there's an AJAX application, and there's natural duration
> between "the first HTML page, and the subsequent AJAX request". I mean it
> takes some time for the browser to parse the initial page, and only then
> AJAX requests are sent. In order to reflect that JMeter would have some
> timer to implement the delay.
> "adjust timers" feature should not impact that delay.
Yes , but this case is already edgy in JMeter as there is no concept of
parallel request.
>
> Note: I don't think this particular type of delay can easily be
> distinguished from true inter-page delays when doing automatic recording.
>
> 3) Service timers that are used to implement "wait for the task" pattern.
> I mean:
> while(!task_ready) {
> sleep(1 min);
> refresh(home screen);
> }
Good catch .
An option would be to introduce a new field on timers to say if it can be
adjusted or not.
Bu default it would be configured to true for all except CTT and Sync timer.
This also solves the ajax case.
>
> I happen to see that pattern quote often.
> That particular "sleep(1min)" should not be "adjusted" (multiplied or
> whatever) since that particular timer is not related to user behavior, but
> it just lets the system to process the data.
>
> So, the problem is "timer's java class" is the same yet the meaning (adjust
> or not) is different.
>
> 4) There might be user-created timers those are completely unknown to
> JMeter. Something should be done for the timers as well.
User just override the ancestor method
>
> 5) Some good wording in documentation is required to make it clear for the
> end-user when the feature should be used, and when it should not be used.
> Of course, every feature can be misused, so "theoretical misuse" should not
> serve as a reason to deny a feature. However, the particular "adjust
> timers" can very easily be confused with "tune throughput" feature. As
> discussed, "throughput" should be tuned by the proper throughput timers.
Yes
>
> Vladimir
>
--
Regards
Ubik Load Pack <http://ubikloadpack.com> Team
Follow us on Twitter <http://twitter.com/ubikloadpack>
Cordialement
L'équipe Ubik Load Pack <http://ubikloadpack.com>
Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
Re: Re: Thoughts on 2 proposals
Posted by Vladimir Sitnikov <si...@gmail.com>.
>In my opinion, this feature could be usefull.
TL;DR: I don't try to prove that the feature is bad. I just don't have
motivation to implement this particular feature, so I list several corner
cases when the feature can behave unexpectedly if implemented in a naive
way.
Let me take a step back.
Here are some corner cases when "adjust timers" feature might harm:
1) Throughput timers. If a timer is set to maintain X requests per second,
then "adjust timers" feature should not adjust that timer. Otherwise the
throughput would be way off.
There is at least one such timer in JMeter core.
2) Suppose there's an AJAX application, and there's natural duration
between "the first HTML page, and the subsequent AJAX request". I mean it
takes some time for the browser to parse the initial page, and only then
AJAX requests are sent. In order to reflect that JMeter would have some
timer to implement the delay.
"adjust timers" feature should not impact that delay.
Note: I don't think this particular type of delay can easily be
distinguished from true inter-page delays when doing automatic recording.
3) Service timers that are used to implement "wait for the task" pattern.
I mean:
while(!task_ready) {
sleep(1 min);
refresh(home screen);
}
I happen to see that pattern quote often.
That particular "sleep(1min)" should not be "adjusted" (multiplied or
whatever) since that particular timer is not related to user behavior, but
it just lets the system to process the data.
So, the problem is "timer's java class" is the same yet the meaning (adjust
or not) is different.
4) There might be user-created timers those are completely unknown to
JMeter. Something should be done for the timers as well.
5) Some good wording in documentation is required to make it clear for the
end-user when the feature should be used, and when it should not be used.
Of course, every feature can be misused, so "theoretical misuse" should not
serve as a reason to deny a feature. However, the particular "adjust
timers" can very easily be confused with "tune throughput" feature. As
discussed, "throughput" should be tuned by the proper throughput timers.
Vladimir
Re: Re: Thoughts on 2 proposals
Posted by Antonio Gomes Rodrigues <ra...@gmail.com>.
Hi
My answers inline below
2016-08-31 1:11 GMT+02:00 harry_no_spot <13...@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" <ra...@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
> >>
>
Re:Re: Thoughts on 2 proposals
Posted by harry_no_spot <13...@163.com>.
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" <ra...@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 <si...@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
>>
Re: Thoughts on 2 proposals
Posted by Antonio Gomes Rodrigues <ra...@gmail.com>.
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 <si...@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
>
RE: Thoughts on 2 proposals
Posted by "Epp, Jeremiah W (Contractor)" <je...@cas.org>.
> -----Original Message-----
> From: Vladimir Sitnikov [mailto:sitnikov.vladimir@gmail.com]
> Sent: Friday, August 19, 2016 8:22 AM
> To: dev@jmeter.apache.org
> Cc: support@ubikloadpack.com
> Subject: Re: Thoughts on 2 proposals
>
> 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.
The actual test plan already isn't a full structural match, but I'm not much
a fan of the idea of making things even less clear. My suggestion would be
to include shortcuts for some common/common-sense fragments in the UI.
e.g. you'd go to the context menu->add->fragment templates->"think delay"
...and it would insert the TestAction and Timer for you.
But if we consider the timers, I think a more useful semantic would involve
the ability to specify that the timer only fires on certain node types as a
standard feature.
e.g. It would be a property of timers and probably look something like so:
<stringProp name="Timer.nodeType">transaction</stringProp>
With this, you could drop two timers into your test plan root to set constant
throughput and the delay between transaction groups and that's all, folks.
Cheers,
Wyatt
Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from Chemical Abstracts Service ("CAS"), a division of the American Chemical Society ("ACS"). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.
Re: Thoughts on 2 proposals
Posted by Vladimir Sitnikov <si...@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
Re: Thoughts on 2 proposals
Posted by Antonio Gomes Rodrigues <ra...@gmail.com>.
Hi
Le 19 août 2016 08:49, "Vladimir Sitnikov" <si...@gmail.com> a
écrit :
>
> >Bug 60018 - Timer : Add a factor to apply on pauses
>
> -1 as the same can be implemented with ${..} or similar existing
> functionality.
How do you want to implement it ?
This feature exist in HP Loadrunner and could be usefull
In Loadrunner I (and other expert xho I know) use it like that :
You record your script with think time
Amd you use this feature to adapt think time to real user without modifying
all the think time
Of ciurse we can already do it with JMeter features but it take more time
And in my opinion, add feature to increase productivity in JMeter is great
because it's one of weakness of JMeter
+1 for me if we have a well integred implemetation
>
> > Bug 60017 - Performance optimisation : Nullify comment field
>
> -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.
> The negative side is clearly visible, but the gain is not, so I'm inclined
> to divert the change.
No opinion
Antonio
>
> Vladimir
Re: Thoughts on 2 proposals
Posted by Vladimir Sitnikov <si...@gmail.com>.
>Bug 60018 - Timer : Add a factor to apply on pauses
-1 as the same can be implemented with ${..} or similar existing
functionality.
> Bug 60017 - Performance optimisation : Nullify comment field
-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.
The negative side is clearly visible, but the gain is not, so I'm inclined
to divert the change.
Vladimir
Re: Thoughts on 2 proposals
Posted by sebb <se...@gmail.com>.
Sorry, but I don't think either request should be implemented.
On 18 August 2016 at 21:11, UBIK LOAD PACK Support
<su...@ubikloadpack.com> wrote:
> Hello,
> We opened today 2 enhancement requests:
> - https://bz.apache.org/bugzilla/show_bug.cgi?id=60018
> - https://bz.apache.org/bugzilla/show_bug.cgi?id=60017
>
> Would you be ok to integrate 2 patches if we implement what we proposed ?
>
> Thank you
> Regards
> UbikLoadPack Team
> @ubikloadpack