Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #8375

Re: NIO multiplexing + thread pooling

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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