Menu
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://mailinator.blogspot.com/2008/02/kill-myth-please-nio-is-not-faster-than.html. I am wondering whether anyone from the Java community has done this kind of benchmarking related to Java NIO performance.
280
Java NIO is an asynchronous IO or non-blocking IO. For instance, a thread needs some data from the buffer. While the channel reads data into the buffer, the thread can do something else. Once data is read into the buffer, the thread can then continue processing it.
nio (NIO stands for non-blocking I/O) is a collection of Java programming language APIs that offer features for intensive I/O operations. It was introduced with the J2SE 1.4 release of Java by Sun Microsystems to complement an existing standard I/O.
Java IO's various streams are blocking. It means when the thread invoke a write() or read(), then the thread is blocked until there is some data available for read, or the data is fully written. Non blocking I/O. Non blocking IO does not wait for the data to be read or write before returning.
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:
Just some food for thought. To answer the question of which is faster, NIO or IO: Both and neither :)
50
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
