Name: 
Avoid NIO, Get Better Throughput
The Java NIO (new/non-blocking I/O) API introduced in Java 1.4 is arguably the most arcane part of the standard library. With channels, selectors, byte buffers and all the associated flipping, marking, compacting, event-handling and registering/de-registering of read/write interest, it’s an entirely different level of complexity to the old-fashioned, straightforward blocking I/O. And if you want to use SSL with NIO then it’s a whole new world of pain.
Few have mastered NIO. For most it provides an opportunity to really get to know your debugger. “Should this buffer be flipped before I pass it to this method, or should the method flip it?”. BufferOverflowExceptions and memory leaks abound.
So, in the spirit of doing the simplest thing that could possibly work, writing your own NIO code is usually best avoided unless you have a compelling reason. Fortunately, some masochistic individuals have done a lot of the hard work so that we don’t have to. Projects such as Grizzly and QuickServer provide proven, reusable non-blocking server components.
However, in most instances, maybe non-blocking I/O is not necessary at all? In fact, maybe it is detrimental to performance?
That’s the point that Paul Tyma makes. He attacks some of the received wisdom about the relative merits of blocking and non-blocking servers in Java. The characteristics of JVMs and threading libraries change as new advances are made. Good advice often becomes bad advice over time, demonstrating the importance of making your own measurements rather than falling back on superstitions.
Paul’s experiments show that higher throughput is achieved with blocking I/O, that thread-per-socket designs actually scale well, and that the costs of context-switching and synchronisation aren’t always significant. Paul’s slides form his talk “Thousands of Threads and Blocking I/O: The Old Way to Write Java Servers Is New Again (and Way Better)” are well worth a look.
If you are writing your own multi-threaded servers in Java, Esmond Pitt’s Fundamental Java Networking and Java Concurrency in Practice by Brian Goetz et al. are essential reading.
on September 3rd, 2008 at 6:58 pm
It seems that the link to the “Thousands of Threads” slides is broken.
Other than that, interesting article. Luckily for me, I never had a need for that low level programming. Interesting enough, I’m going to be doing the SCJD certification soon, and in the requirements is explicitly stated that no java.nio is allowed. Instant fail if you do (but it also mentions that you need to use the JTable).
on September 3rd, 2008 at 7:55 pm
MLeo, thanks, I just fixed the link.
on September 4th, 2008 at 10:01 am
“Avoid superstition.”
or do no trust sales men.
did not manage to find the benchmark code for Paul Tyma claims.
. so…
sceptical about the article.
on September 4th, 2008 at 2:58 pm
Tomcat 6 running with the NIO conector works marvelous
and its Throughput is order of magnitude better thatn tradition i/o blocking at leat for my application
on September 5th, 2008 at 9:39 am
[...] New Adventures in Software » Avoid NIO, Get Better Throughput [...]
on September 11th, 2008 at 7:09 am
I recently got a significant improvement in performance using NIO in a blocking mode with one thread per connection. Its a combination I wouldn’t have thought of not long ago, but when I tested it got request/response time very close to that of a ping.
I agree that the trick about performance is don’t assume, test because you will be surprised how often you would be wrong about these things. It keeps things interesting IMHO