I finally had an opportunity to perform some performance testing on the source I made available.
- It was not a closed environment. It is a cluster of machines running Linux (2.4.21) with MOSIX with a number of NFS mounted drives. There were a few other processes bouncing around the cluster at the time. This caused a number of dips in the throughput. All processes for this test were pinned to their respective machines.
- All machines are AMD Athlon(tm) XP 2500+ with 512MB RAM
- Sun JDK 1.4.2_05
- The network is 100Mb but it is not known if it is switched (highly doubtful)
- The echo server was started. The first connected to the server, followed by the second approximately seven second (arbitrary) later, followed by the third approximately seven seconds later, etc for all five clients.
- Each client transferred 500MB to the server before disconnecting.
- The data sent from the clients is random and in random sized batches of less than 4096 bytes.
- All data received by the server is immediately written back to the client.
- The clients wait for the server to echo back their batch of data and validate it before sending another.
As with most performance tests, the results must be interpreted correctly and cannot be taken at face value. You should not look at absolute values but instead you should look at relative values and trends. For “pure test” results the environment was not ideal but for a more “real world” feel for how applications behave, the environment was adequate.
There are a total of six cases:
- NIO Server, NIO Client
- NIO Server, Converted IO Client
- Converted IO Server, NIO Client
- Converted IO Server, Converted IO Client
- Converted IO w/ Selector Server, NIO Client
- Converted IO w/ Selector Server, Converted IO Client
“NIO” means that the component was created using only NIO. “Converted IO” is an NIO wrapper to
OutputStream. The server with “Converted IO” uses a separate thread per client. The server with “Converted IO w/ Selector” uses a single thread for all clients and switches between them using an NIO
All of the source for the clients and servers is available but the test harness is not available. It should be a trivial matter to create you own testing mechanism ideal for your environment.
Ideally, there should be a standard Java IO implementation as a control but unfortunately time is not on my side.
- The large dips in the graphs were caused by MOSIX and the processes that were running on the clusters.
- The NIO server performed slightly better than the Converted IO server as expected since the Converted IO server has an additional delay associated with the pipe that converts from standard IO to non-blocking IO. The difference between ~7.5 MB/s (Converted IO) and ~9.5 MB/s (NIO) (~20% difference) is significant and further work needs to be performed to tune Converted IO.
- The NIO client performed slightly better than the Converted IO client (for the same reasons as the server).
- The selector-based server to multiplex multiple clients performed worse than using a separate thread per client. Based on other results found on the internet, this is a typical result. The overhead of the selector is not mitigated with only a few clients.
- The fluctuation of the selector-based server was not expected. Further investigation is warranted.
- It appears that client 3 was not behaving consistently as is seen by its lower throughput and longer times. It is understandable that client 3’s trend is not seen in the “Converted IO Server, NIO Client” case considering the large number of times that MOSIX interfered.
A special thanks goes out to Carlo Segre for use of the cluster.
Link-back to main entry: NIO and SSL.