Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #8375
| From | Tom Anderson <twic@urchin.earth.li> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: NIO multiplexing + thread pooling |
| Date | 2011-09-27 20:52 +0100 |
| Organization | Stack Usenet News Service |
| Message-ID | <alpine.DEB.2.00.1109272044210.14737@urchin.earth.li> (permalink) |
| References | <CAA3EEF8.78BF%bravegag@hotmail.com> <alpine.DEB.2.00.1109242028540.12593@urchin.earth.li> <9e8aqfFnorU1@mid.individual.net> |
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
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar
NIO multiplexing + thread pooling Giovanni Azua <bravegag@hotmail.com> - 2011-09-24 20:32 +0200
Re: NIO multiplexing + thread pooling Tom Anderson <twic@urchin.earth.li> - 2011-09-24 20:46 +0100
Re: NIO multiplexing + thread pooling Giovanni Azua <bravegag@hotmail.com> - 2011-09-24 23:09 +0200
Re: NIO multiplexing + thread pooling Robert Klemme <shortcutter@googlemail.com> - 2011-09-25 11:33 +0200
Re: NIO multiplexing + thread pooling Tom Anderson <twic@urchin.earth.li> - 2011-09-27 20:52 +0100
Re: NIO multiplexing + thread pooling Robert Klemme <shortcutter@googlemail.com> - 2011-09-28 08:21 +0200
Re: NIO multiplexing + thread pooling markspace <-@.> - 2011-09-28 08:20 -0700
Re: NIO multiplexing + thread pooling Robert Klemme <shortcutter@googlemail.com> - 2011-09-28 18:56 +0200
Re: NIO multiplexing + thread pooling markspace <-@.> - 2011-09-28 11:07 -0700
Re: NIO multiplexing + thread pooling Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-09-28 17:39 -0700
Re: NIO multiplexing + thread pooling markspace <-@.> - 2011-09-29 09:25 -0700
Re: NIO multiplexing + thread pooling Lew <lewbloch@gmail.com> - 2011-09-30 07:46 -0700
Re: NIO multiplexing + thread pooling markspace <-@.> - 2011-09-30 08:22 -0700
Re: NIO multiplexing + thread pooling Lew <lewbloch@gmail.com> - 2011-09-30 08:30 -0700
Re: NIO multiplexing + thread pooling markspace <-@.> - 2011-09-30 08:49 -0700
Re: NIO multiplexing + thread pooling Robert Klemme <shortcutter@googlemail.com> - 2011-09-30 20:57 +0200
Re: NIO multiplexing + thread pooling "John B. Matthews" <nospam@nospam.invalid> - 2011-09-25 00:26 -0400
Re: NIO multiplexing + thread pooling Giovanni Azua <bravegag@hotmail.com> - 2011-09-25 11:13 +0200
csiph-web