jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From UBIK LOAD PACK Support <>
Subject Re: Thoughts on 2 proposals
Date Wed, 31 Aug 2016 06:33:53 GMT
Hi all,
Some answers inline below.

On Wednesday, August 31, 2016, Vladimir Sitnikov <> 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.

as explained in bugzilla, this will be handled through a method
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.


> Vladimir


Ubik Load Pack <> Team
Follow us on Twitter <>

L'équipe Ubik Load Pack <>
Suivez-nous sur Twitter <>

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