金床氏によるブログ記事です。金床氏はWebアプリケーションセキュリティに造詣が深く、書籍を著していたりJavaによるWAF（Web Application Firewall）やHTTPプロキシツールを開発していたりします。その中のWAFである「Guardian@JUMPERZ.NET」のアーキテクチャはスレッドプール＋ブロッキングI/Oを採用しており、世でC10K問題[1]の解決案とされている非同期I/Oを利用したものではありません。そして世間で注目されているJava NIO（New I/O）を利用した場合、本当によりスケールするのか検証を行っています。

実際にNIOベースに書き換えるのはハードルが高いため、NIOで実装しているいくつかのプロダクトを試しています。TomcatのNIOモードとGuardian@JUMPERZ.NETでベンチマークをとったところ、どちらも十分なパフォーマンスを得られ有意な差は見られませんでした。また、ベンチマークの過程でTomcatやJBoss Netty[2]⁠、Apache HttpComponentsといった一連のNIOプロダクトにて負荷をかけるとTCPコネクションが張れないエラーが発生したそうです。金床氏の調査ではJava NIOにバグがあるのではないかと疑っています。

一連の検証の結果、メモリを豊富に積めば1万以上ものスレッドを扱うことができ、Linux 2.6のスレッド実装が優秀でコンテキストスイッチのオーバヘッドが問題ならないこともあり「HTTPサーバのようなFIFO（First In First Out）的に処理するシステムにおいて必ずしもJava NIOを使う必要はない」という結論に達しています。

URL：http://kanatoko.wordpress.com/2011/02/15/http_server_and_java_nio/