Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #8268
| From | Tom Anderson <twic@urchin.earth.li> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: NIO multiplexing + thread pooling |
| Date | 2011-09-24 20:46 +0100 |
| Organization | Eindhoven University of Technology |
| Message-ID | <alpine.DEB.2.00.1109242028540.12593@urchin.earth.li> (permalink) |
| References | <CAA3EEF8.78BF%bravegag@hotmail.com> |
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. > From all code examples/tutorials/books I have reviewed online the > "Selector Thread" seems like a bottleneck to me. If the selector thread's only job is to identify channels which are ready to be worked on, handing them off to worker threads to be processed, then it doesn't really have a lot of work of its own to do, and so it's unlikely to be a bottleneck. 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. One thing you could consider, if using a single selector thread and a pool of worker threads, is trying to create some affinity between channels and threads, so that the same thread always handles the work on a particular channel (and on several channels); on a multiprocessor machine, this should increase cache performance, but is not otherwise particularly valuable. This is not entirely straightforward, because of thread and channel starvation issues; you should read up on work-stealing if you want to do that. tom -- And the future is certain, give us time to work it out
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