See below... On Tue, Feb 15, 2011 at 12:01 PM, Emmanuel Lecharny <[email protected]>wrote:
> On 2/15/11 8:49 PM, John Fallows wrote: > >> Jason, >> > John, more in line... > > As you know, with non-blocking I/O a small number of threads are servicing >> a >> potentially large number of connections (as opposed to blocking I/O with 1 >> thread per connection). Therefore synchronization can potentially have a >> dramatic effect when attempting to scale up if there is the possibility of >> lock contention across more than one thread where one of those contending >> threads is an I/O thread. All connections serviced by the same I/O thread >> are affected by such a scenario. >> >> We saw active connections serviced by the same I/O thread pause throughput >> while processing the request to close other sessions serviced by the same >> I/O thread. Eliminating the lock prevented the blocking behavior. With a >> small number of connections or low throughput, the pause may not be >> noticeable, but at high load it became much more obvious. >> > Can you provide a bit more info about the load you are experiencing ? That > would be interesting for all the mailing list subscribers to know about real > life examples... > > In this particular example, we were running 20k connections and validating the effects of closing and then re-opening a further 10k connections. Kind Regards, John Fallows > Many thanks ! > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > > -- >|< Kaazing Corporation >|< John Fallows | CTO | +1.650.960.8148 444 Castro St, Suite 1100 | Mountain View, CA 94041, USA
