NIO Performance Improvement compared to traditional IO in Java

Question

I have seen many articles/blogs saying that Java NIO is a better solution compared to traditional Java IO.

But today one of my co-worker showed me this blog http://m

Answer 1

NIO vs IO is a pretty fun topic to discuss.

It's been my experience that the two are two different tools for two different jobs. I have heard of IO being referred to as the 'Thread per Client' approach and NIO as the 'One thread for all Clients' approach and I find the names, while not 100% accurate, to be fitting enough.

The real issue with NIO and IO, as I see it, is with scalability.

An NIO network layer will (should?) use a single thread to handle the selector and dispatch read/write/accept jobs to other thread(s). This allows the thread handling the selector (the 'Selector Thread') to do nothing but just that. This allows for much faster response when dealing with a lot (note the lack of actual numbers) of clients. Now, where NIO starts to fall apart is when the server is getting so many read/write/accept that the Selector Thread is constantly working. Any additional jobs past this and the server starts to lag. Additionally, since all read/write/accept jobs are processed by the Selector Thread, adding additional CPUs to the mix will not improve performance.

An IO network layer will likely take the approach of 1 thread per socket, including the listening socket. So the number of threads is directly proportional to the number of clients. Under a moderate amount of clients, this approach works really well. The cost that one pays by using this approach comes in the form of the cost of a thread. if you have 2000 clients attached to a server... you have at least 2001 threads. Even in a quad chip, 6 core per chip machine, you only have 24 processing nodes (48 if you count HyperThreading) to handle those 2001 threads. Instantiating all those Threads costs cpu time and ram, but even if you use Thread Pooling, you still have to pay the cost of the CPUs context switching as they move from thread to thread. This can get very ugly at high server loads, and, if not coded properly, can grind the entire machine to a halt. On the plus side, adding CPUs to the machine WILL improve performance in this case.

Now all that is well and good, but is in the abstract because there's no numbers in my description to aid in making a decision to go with IO or NIO. This is because there's even more variables to consider:

• Life time of a client? Short or long?
• Amount of data expected per client? Lots of small chunks or few huge chunks?
• Just how many clients are expected to be connected simultaneously?
• What OS are you on and what JVM are you using? Both factor into Thread and polling costs.

Just some food for thought. To answer the question of which is faster, NIO or IO: Both and neither :)