Again, use the right tool (or in this case internal application architecture/design) for the job.
If your application _never_ blocks when it's performing it's 'logic' then you shouldn't have a worker pool - just do everything on the IO thread(s). If your application will block because it uses a DB w/ blocking IO driver, accesses the file system using blocking IO, etc then you probably want a separate worker pool. (The real question is, how strict should the no blocking in the IO thread rule be. If your using just about any existing logging framework you have the potential to block, even when using 'buffered loggers'. If you use Java synchronization anywhere in your application logic, even if you do no other IO at all, you have the potential to block.) If you decide to go NIO and not use a worker pool you _can_ still take full advantage of your CPU/cores by having multiple IO threads. I don't think having all these options for NIO is too difficult. Yes, the developer has to put more thought into the IO design of the application. But sticking your head in the sand and just using blocking IO all the time isn't a good solution either. It's a good thing NIO has all these options because that's what allows you to build applications that would be impossible or inefficient with blocking IO. For example, take a look at XMPP/Jabber. The server must support permanent TCP connections from clients, and only when people are actively sending messages is there any real traffic. So this is a perfect example of needing a lot of open, but mostly idle connections. With blocking IO each server could handle a few hundred to a couple thousand connections. With Linux and NPTL you might get to 4-5K connections per box. To support hundreds of thousands of users you'd need hundreds of thousands of boxes. Using NIO, each box can handle many more connections, probably 10-100K each. You've just divided the number of boxes you need by at least 5, maybe up to 20 or more!! Rob ----- Original Message ---- From: Daniel Cheng <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, February 22, 2008 10:34:42 PM Subject: Re: NIO vs NPTL+standard IO Rob Butler wrote: > I suspect this comes down to using the right tool (or API) for the job. > > * Latency will be lower with normal IO because only a single thread is > involved with no hand-off between the IO thread and the 'worker' thread. I really doubt if we should use separate worker thread in NIO. In the ideal case, all threads are never blocked -- (1) the IO thread keep pumping the data from/to the network; (2) the worker thread keep work on tasks. There are no context switching, each and every thread have its own CPU. People think no blocking == no context switching == no time wasted. However, in x86, if you hand over objects from one thread to the other... The whole (CPU) cache line have to be invalidated (in x86, one and only one CPU can hold a piece of memory in cache at the same time... and raw memory access is *slow*).. If you use a single java arrays to store tasks, values are likely to be clustered together in memory. Invalidating one value may invalidates all of them. This doesn't sounds too good to me. Maybe a separate queue for each worker thread is better? The CPU cache can be invalidated less frequently. Maybe we should just do all the work on i/o thread? But then we cannot use all of the CPU... Maybe one "Selector" thread and one "I/O + worker" thread is better? So we can read the data on where we process it... But it sounds hard to be implemented right.. If you consider all of these..... NIO is just *too* difficult to be implemented correctly. And all of these can be application specific... > * In general throughput will be higher with normal IO as long as the > number of connections/threads is reasonable. Probably a few hundred > simultaneous connections/threads on most OS's, more on Linux with NPTL. > You can probably get to 4-5K connections/threads on NPTL safely, but now > your limited to only running on Linux with NPTL. If you want that many > simultaneous connections on other OS's, you should use NIO. > > * If your needs are lots of simultaneous connections (10K or more), that > aren't very IO heavy, NIO is the way to go - even on NPTL. > > You can't even say that an HTTP server should use normal IO, or should > use NIO - because it depends on how the HTTP server is going to be used. > If your going to have lots of clients doing ajax stuff or using > continuations, go with NIO. If not, use normal IO. > > Rob > -- ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
