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

There is no inherent reason why one is faster than the other.

The one-connection-per-thread model is currently suffering from the fact that Java thread has a big memory overhead - thread stack is preallocated to a fixed (and big) size. That can be and should be fixed; then we can cheaply create hundreds of thousands of threads.

Answer 2

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

Answer 3

A is faster than B is often a very simplistic view and sometimes plain wrong.

NIO is not automatically faster than plain IO.

Some operations are potentially faster using NIO and you can scale to many network connections much easier with NIO (because you don't need one thread per connection).

But NIO is not a magic "make stuff faster"-switch that needs to be applied to everything.

Answer 4

The problem with the article is it compares blocking IO vs non-blocking NIO. In my own tests comparing blocking IO vs blocking NIO (more like for like) NIO is up to 30% faster.

However unless your application is trivial, like a proxy server, its is unlikely to matter. What the application does is far more important. Both IO and NIO have been tested with up to 10,000 connections.

If you want super fast IO you can use Asynch IO (Java 7+) with Infiniband (not cheap, but lower latency)