Le 4/19/14 9:45 AM, Alon Bar-Lev a écrit : > On Sat, Apr 19, 2014 at 10:38 AM, Emmanuel Lécharny <elecha...@gmail.com> > wrote: >> Le 4/19/14 9:13 AM, Alon Bar-Lev a écrit : >>> Hi, >>> >>> The mission of async is to avoid having threads at all, or at least O(1). >>> >>> As you have underline internal/private low level channels for socket >>> processing, and public high level channels to communicate with >>> application, there should be a mechanism for library to request wake >>> up for these low level channels. >>> >>> Another option is to avoid using sockets at all within the >>> implementation and require application to manage the sockets and pipe >>> socket data into the library. >>> >>> I understand this is conceptional change than what we have now, but >>> this what will enable scale without abusing system threads or have >>> nondeterministic behaviour in high load. >> There are a few important things you have to know about async and threads : >> - the extra cost for dealing with async connection is around 30%. That >> all but free >> - a standard system can easily deal with a few thousands of threads >> >> Now, unless you define what is "high load", I don't really see what kind >> of advantage we can get with an async implementation. >> >> FTR, when MINA was initially created, it was because there was a need >> for a system supporting potentially ten of thousands of connections. Is >> that what you are targetting ? > Yes, using work threads that are derived per # of CPUs, no more. > I am far from the pure "Java" world... but if async IO is 30% > insufficient, maybe it worth to use libssh (C) and communicate with it > using single socket from java, delegating IO outside of java. IO are already delegated outside on Java. Eveything IO related is written in C and wrapped into Java class.
The extra cost when using NIO is due to the management of SelectorKey lists (with the various steps involved when dealing with those lists). All in all, when it comes to process IO, Java does not really add some extra cost over a plain C implementation. It's not the same story when using NIO, especially when dealing with many concurrent connections. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
