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 > --
