On Tue, May 12, 2009 at 6:47 PM, Jeanfrancois Arcand <
Jeanfrancois.Arcand_at_sun.com> wrote:
> Salut,
>
> John Franey wrote:
>
>
>>
>> On Tue, May 12, 2009 at 5:56 PM, Jeanfrancois Arcand <
>> Jeanfrancois.Arcand_at_sun.com <mailto:Jeanfrancois.Arcand_at_sun.com>> wrote:
>>
>> Salut,
>>
>>
>> John Franey wrote:
>>
>> Hi,
>>
>> I'm trying to get a handle on how threads are being used in
>> 1.9.16-SNAPSHOT (svn r3170). I currently have two areas of
>> outstanding questions.
>>
>> 1) I see leader-follower strategy. When in use, a worker thread
>> from the controller's threadpool is used for the
>> SelectorHandlerRunner. When a selected event occurs,
>> delegateToWorker branch of SelectorHandler.handleSelectedKey,
>> the current thread requests another thread to become the
>> selector thread, and handles the key processing itself,
>> returning itself to the thread pool on completion.
>>
>> So far so good.
>>
>>
>> This is
>>
>> different from a strategy where the selector thread requests
>> another thread to do the key processing, and retains the role as
>> selector thread. Is this correctt?
>>
>>
>> Yes.
>>
>>
>> Is this strategy effective if there is more
>>
>> than one selector key (event) to process? or, under what
>> conditions is this strategy ineffective/effective?
>>
>>
>> Usually leader/follower gives better results, but our measurement
>> didn't show a boost like we were expected. We got a ~4% boost.
>>
>> I'm not sure I see it working, at all. I'm using yourkit profiler to show
thread telemetry. Looks like the selector thread (Grizzly-Worker-0) is
always runnable, and the other worker threads are runnable only part of the
time. I might be reading the tool wrong.
>
>>
>>
>>
>> 2) I see that Controller.autoConfigure sizes readThreadsCount
>> (by the number of processors). This value is used later in
>> Controller.start to create a RoundRobinSelectorHandler; for each
>> of readThreadsCount, a ReadContoller is created. When
>> acceptInterest occurs, RoundRobinSelectorHandler will pick one
>> of the ReadControllers and assign the selected channel to it.
>>
>>
>> Yes.
>>
>>
>> Each ReadController runs its own
>>
>> SelectorHandler thread, and so, selection work is distributed
>> across a group of threads (sized by the number of processors).
>> It looks like this action of distributing selection across
>> threads will only be activated onAcceptInterest, and in cases
>> where a server does not bind, this won't occur. Is that correct?
>>
>>
>> Yes. And the performance out-of-the-box is 50% higher.
>>
>>
>> In absence of onAcceptInterest
>>
>> callbacks (no binding), can selection work be distributed across
>> threads?
>>
>>
>> Can you elaborate about this scenario?
>>
>>
>> Sure. I'm still not connecting all the dots yet, so I hope I make sense.
>>
>> I'm working on an implementation of an RTP media server. This uses UDP.
>> UDP doesn't use accept. A peer uses datagram connect with local and
>> remote ip addresses and starts to send and receive RTP, UDP packets. The
>> remote ip address is pre-negotiated using a different protocol, not RTP.
>> There is no connection setup. There is not a bind operation. There is no
>> connection to accept. I expect the only selected keys would be for either
>> for OP_READ and OP_WRITE, and OP_CONNECT.
>>
>
> OK I get it it :-) So you should not be impacted by the change as it is
> just for OP_ACCEPT. But it should probably be a good optimization to use one
> Selector to handle OP_READ per thread.
>
>
>
>> 50%, heh? That's a big improvement. In what metric? throughput, cpu
>> utilization?
>>
>
> Throughput if you were testing on a machine that has more than one
> core/processor. Single processor no effect :-)
>
>
> Do you think its possible for UDP handlers to enjoy this?
>
> Yes I think we need to implement it (simple IMO) and add support for
> OP_READ round robin.
>
Sure, I vote yes. If by 'we' you mean to include me, I'd like to take a try
at it, seeing I'm the one to mostly benefit. Unfortunately, the simplicity
is not obvious to me (the dots are still not connecting). If you have the
time to jot down a few starter instructions, I'll see what I can do with it.
Can I at least post an issue?
Thanks,
John
>
> A+
>
> -- Jeanfrancois
>
>
>> Thanks.
>> John
>>
>>
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>>
>>
>>
>> Thanks,
>> John
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> <mailto:users-unsubscribe_at_grizzly.dev.java.net>
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>> <mailto:users-help_at_grizzly.dev.java.net>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>