Re: NIO multiplexing + thread pooling
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