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.
>
>
>
>
>
> 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.
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>
>
>