Salut,
John Franey wrote:
>
>
> On Tue, May 12, 2009 at 6:47 PM, Jeanfrancois Arcand
> <Jeanfrancois.Arcand_at_sun.com <mailto: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>
> <mailto: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.
As soon as you do a request Worker-0 will always be active. Are you
stressing the server by any chance?
>
>
>
>
>
>
> 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.
Yes if you can start, we can jump in as soon as you have something ready.
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?
Yes do that, and I will add my comments there.
Thanks!
-- Jeanfrancois
>
>
> 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>
> <mailto: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>
> <mailto: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
> <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>
>
>