Re: [jetty-dev] SelectSet optimization

[Greg Wilkins <gregw@xxxxxxxxxxx>]

Hmmm the failure goes away whenever I look closely at it.  I was
thinking it was a FD exhaustion thing, but now I'm not so sure.

I have tried several variations on the select - deferring the
interestedOps set to 0 and checking the selectedKey set is empty etc.
None of these have made any appreciable difference to throughput or
latency that I can measure with the stress test.

So it kind of says the optimisation is no longer needed.... but then
I'm not sure if it is yet worth changing that code and perhaps causing
problems?

Trying to focus on this occasional failure instead now

cheers


On 10 January 2011 11:57, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
> Simone,
>
> I instrumented the select manager and ran the StressTest class with
> -DSTRESS=true and got results like:
>
> selected=488481
> cleared= 146416
>
> This says that from 488k scheduled endpoint, 146k of them were already
> dispatched, so the interested ops were cleared.
> So  for 195k events, we avoided clearing the interestedOps AND avoided
> a second dispatch, but for 146k events, we ended up dispatching twice
> and clearing the interested ops.
> So the question is, which is more expensive:  195k setting/clearing of
> the interested ops, or 146k unnecessary schedules (note these are done
> in selector thread and really just cost another synchronisation.
>
> But more worryingly, the StressTest itself is currently failing
> frequently with -DSTRESS=true -  so I'm going to investigate that
> first.
>