jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Design of Timeout test element / sampler interrupter
Date Sun, 30 Aug 2015 11:58:28 GMT
Hi,
Few other thoughts.
If you look at :
http://mail-archives.apache.org/mod_mbox/jmeter-user/201508.mbox/%3CCAKUYAYdrHq7YiRzK3wto7200K8VkhVZK4Joe3-FsKE%2BUXQj26Q%40mail.gmail.com%3E

In my understanding the user is looking for a way to timeout within the
chunks receival, so it looks tightly related to 1 protocol HTTP.
Or maybe I didn't understand.

Now if we consider the design of Timeouter, is it really so frequent to
have 1 same timeout for all elements ?
I tend to think it's not the case, so I am not sure you will take benefit
of scoping.

And even in this case, HTTP Request it can be set in defaults.

If not, then it means you will end up putting a different one per sampler,
so shouldn't it be in the Sampler .

One case I see is a timeout of a whole Business Transaction (Transaction
Controller), then it would be useful but only for the Transaction
Controller that contains the different elements of Transaction Controller.

In this case the scoping is not needed and must even more be avoided. So to
do this, how would you proceed with this element ?

So thinking more about it, I don't see for now why it would be better to
have a new Element instead of adding this behaviour at AbstractSampler
level ?
Can you give me some examples you have in mind ?

Thanks

On Sun, Aug 30, 2015 at 12:54 PM, sebb <sebbaz@gmail.com> wrote:

> On 30 August 2015 at 07:12, Philippe Mouawad <philippe.mouawad@gmail.com>
> wrote:
> > On Sunday, August 30, 2015, sebb <sebbaz@gmail.com> wrote:
> >
> >> I've had a look at the classes that implement SampleListener, and
> >> apart from ResultAction and TransactionSampler, only the Listeners use
> >> it. Since usage of these should be minimised in a production test,
> >> it's likely that there won't be as many implementations as I had
> >> feard.
> >
> > Implementation of SampleListener ?
> > Usage of which should be minimised ?  SampleListener ?
>
> Usage of additional  Listeners should be minimised in a production test.
>
> >>
> >> Also if the implementation is empty, the overhead will be quite small.
> >>
> >> [There is a work-round if it does prove expensive: the SampleListener
> >> interface could be split into two parent interfaces.]
> >>
> >> So assuming that JMeterThread implements sampleStarted/sampleStopped,
> >> the Timeout element can use the Start to set up the timer and the Stop
> >> to cancel it. This will reduce the number outstanding as much as
> >> possible.
> >>
> >> The timeouts have to be implemented using separate threads for two
> reasons:
> >> - it's obviously not possible to interrupt a sampler from the same
> >> thread as the sampler
> >> - depending on the sampler, and its state, the interrupt may take a
> >> while to complete, so each interrupt must be done in its own thread
> >
> > Are you sure, calling interrupt is usually just about setting a flag no?
>
> Ultimately yes, I guess a flag will be set.
> However I'm not sure that it is always instantaneous, as there may be
> locks to aquire.
>
> > Having 1 thread for each interruption, could lead to hundred of
> > threads running for high throughput threads (500 res/s for example), it
> > won't scale.
>
> That assumes that all the samples in all the threads have timeouts enabled.
>
> > Why can't we have 1 Thread (TimeoutChecker) called every N milliseconds
> > that checks all registered JMeterThreads to check and call interrupt if
> > necessary ?
> >
>
> That's quite a bit of work to code, but if there is already such a
> queing mechanism it would be worth trying.
>
> >
> >> It should be possible to use a single shared instance of the
> >> ScheduledExecutorService; that could be lazily created using IODH. [I
> >> can try that with the current implementation]
>
> I've already tried it.
>
> > See my note above
>
> >
> >>
> >> As to whether the Timeout class should be a Timer or some other type
> >> of test element - that does not matter so long as it can be applied to
> >> the samplers individually or when in scope.
> >>
> >> I chose Timer because it was already called in the right place, but I
> >> assume JMeterThread can call any Test class provided that it
> >> implemented the SampleInterface.
> >>
> >> It must be one of the existing Test Element classes that are handled
> >> by the Menu system otherwise it will need special handling.
> >>
> >> The scope requirement rules out Config elements and Logic Controllers.
> >
> > It does not seem like a pre-processor to me, nor a post-procesor, nor a
> >> Listener
> >>
> >> So AFAICT the only remaining options are the Timer and Assertions.
> >>
> >> I think both are justifiable.
> >
> > Why isn't it part of Sampler abstract class and as such a field in
> Sampler?
>
> How does the user indicate that a Timeout should be applied to a
> particular Sampler?
> It's a lot of work to add Timeout fields to every GUI.
> Whereas being able to add a child test element to each applicable
> sampler is already supported.
> Further, such a test element can be applied to multiple samplers in scope.
> Much easier to enable and disable a single element that having to
> update each Sampler.
>
> That's why it needs to be a separate test element.
>
> >
> >
> > For me none of Timer nor Assertions are conceptually valid.
> > The behaviour is not a pause(so not Timer for me), it's not an Assertion
> > neither as for me an Assertion only checks something.
> > Although not fully satisfying it look to me more of a PreProcessor as it
> > sets a timeout on the Sampler , it can also be considered as a Post
> > Processor.
>
> OK, I could live with it being a Pre-Procesor.
> That has the correct scoping rules.
>
> >
> >
> >>
> >> The name of the class can of course be changed from InterruptTimer - I
> >> think that is probably not the best choice. Maybe something like
> >> SamplerTimeout?
> >>
> > Yes or SamplerTimeouter or SamplerInterrupter
> >
>
> Or even SampleTimeout - that's what it does, it applies a timeout to a
> sample.
>
> > --
> > Cordialement.
> > Philippe Mouawad.
>



-- 
Cordialement.
Philippe Mouawad.

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