jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Design of Timeout test element / sampler interrupter
Date Sun, 30 Aug 2015 10:54:52 GMT
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.

Mime
View raw message