WAS Channel Framework: AIO versus NIO

Resolving The Problem

Beginning from WAS 6.1, IBM Java 1.5 offers the AIO (Asynchronous I/O) framework as an alternative to the default Java NIO (New I/O) used for network traffic. Java NIO is still used for some filesystem reading and writing operations throughout WAS code.

While AIO is enabled by default on WAS, it is possible to disable it. In the past, this was sometimes recommended in very specific scenarios, mostly related to performance. To understand why AIO is enabled by default, let’s consider the following advantages it offers:
*Better response time across the board
*More advanced logging features, some of which are required for use with IBM log analyzer tools
*Continuing enhancements and optimizations for WebSphere and other products using IBM Java

These advantages do come at a slight cost. AIO achieves its performance gains by operating on I/O buffers asynchronously, which takes more memory and more total cycles across a multicore CPU. Performance on a single core is identical to NIO, but since AIO is able to utilize multiple cores it will end up using more total CPU resources in a multicore system, and slightly more memory to keep track of the additional work it is doing.

In the case of AIO versus NIO, the performance gains alone afforded by AIO are directly proportional to the additional resources required by the framework, so it is almost always recommended to keep AIO enabled. The additional logging is also a great bonus.

Unless directed otherwise by IBM support, we do not recommend that AIO ever be disabled for WAS. If it has been disabled on your server, for a reason other than native memory use, please update to the latest fixpack and re-enable it.