Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!cs.uu.nl!news.stack.nl!.POSTED!ipv6.urchin.earth.li!twic From: Tom Anderson Newsgroups: comp.lang.java.programmer Subject: Re: NIO multiplexing + thread pooling Date: Tue, 27 Sep 2011 20:52:31 +0100 Organization: Stack Usenet News Service Lines: 59 Message-ID: References: <9e8aqfFnorU1@mid.individual.net> NNTP-Posting-Host: ipv6.urchin.earth.li Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Trace: mud.stack.nl 1317153151 96588 2001:ba8:0:1b4::6 (27 Sep 2011 19:52:31 GMT) X-Complaints-To: abuse@stack.nl NNTP-Posting-Date: Tue, 27 Sep 2011 19:52:31 +0000 (UTC) User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) In-Reply-To: <9e8aqfFnorU1@mid.individual.net> Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8375 On Sun, 25 Sep 2011, Robert Klemme wrote: > On 09/24/2011 09:46 PM, Tom Anderson wrote: >> On Sat, 24 Sep 2011, Giovanni Azua wrote: >> >>> would it increase performance to setup a Thread Pool and associate one >>> SelectionKey to one specific Thread in the pool so that all read/write >>> operations for each specific channel go through one specific Thread >>> from the Pool? >> >> That would not be a thread pool. That would be a thread-per-connection >> model. I can't say that the performance would be worse than with a real >> thread pool, but i doubt it would be better than using blocking IO. > > As far as I can see Giovanni did not say that there was a 1:1 relationship > between threads and channels. I think i read "associate one SelectionKey to one specific Thread" as meaning that, but evidently wrongly. > The approach does actually make sense if there is a fixed limit on the > number of channels one thread is responsible for. The idea being that a > single thread can pull of just that much IO and if the number of clients > is not limited a single thread may indeed be the bottleneck. On the > other hand this approach does create less threads than the thread per > connection model with blocking IO. Hold on - there are two things here. One, an N:M threading model, where you have N connections being served by M threads, where N >> M. That, i readily agree, could offer better performance than N:N or N:1 models. But two, the idea that the M threads should have affinity for connections - that, in effect, we would have an M*(N/M:1) model (i'm sure that notation is crystal clear!). That, i am skeptical about. >> If you're processing the channels in the selector thread (in which case >> it's not really a selector thread), then it could be a bottleneck. So, >> you can have several of them; Selector.select() is threadsafe, so with >> a little attention to locking, you can have many threads selecting and >> then working. This is called the leader/followers model. > > I think the approach with fixed responsibilities of selector threads to > multiple channels scales better than using a single Selector for all > channels from multiple threads. Yes. The latter is sort of N:1:M, and that has twice as many colons, where colons are communication overhead. But i don't see why the thread-affine M*(N/M:1) model would be any faster than the simpler N:M (leader/followers) model. tom -- We discovered in Nature's work a pattern of sloppiness, indifference to basic scholarly standards, and flagrant errors so numerous they completely invalidated the results. -- Encyclopaedia Britannica