WebSocketが一番速いアプリケーションサーバはどれだ？：Tomcat、Jetty、Socket.IO／Node.js性能比較（3/3 ページ）

双方向通信を実現するHTML5関連技術WebSocketを実装した3つのアプリケーションサーバの実装の違い・性能などを徹底検証する。

[高橋栄二，NTTソフトウェア 技術開発センター OSS基盤技術部門]

テスト結果―どれが一番速かったのか？

テストケース【1】同時受信パターンの結果

最大送信時間

　大量のクライアントに対する送信に関しては、Tomcat／Jettyともに送信用のスレッドは1つであるため、1プロセス1スレッドのNode.jsとは大きな差はないものと予想していました。

　結果のグラフは、送信開始時間とクライアントでの受信時間の差の最大値を表したもので、10回のテストの結果を折れ線グラフで表しています。

　グラフを見て分かる通り、Tomcatが一番遅く、Jettyと比較しておよそ2倍強、Node.jsと比較しても1.5倍程度となっています。

　詳しい調査を行ってはいませんが、おそらくTomcatの実装でテキストメッセージは全てByteBufferに変換してから送信しているため、このオーバーヘッドが積み重なった結果であると考えられます。

テストケース【2】同時送信パターン

通信時間平均

　大量クライアントからの受信に関しては、シングルスレッドとマルチスレッドの差が出ることを予想していました。

　結果のグラフは、送信時間と受信時間の差の平均を表したもので、10回のテストの結果を折れ線グラフで表しています。

　この中ではJettyが一番安定しており、サーバ側では目立った性能劣化も起きていません。GCログを見てもConcurrentMarkSweepGCも発生しておらず、マイナーGCも0.1秒程度と問題ない数字となっています。

Jetty GCログ

　次にTomcatですが、結果ごとに、ばらつきが大きく最も遅い場合は109ミリ秒、最も早くても11ミリ秒と、Jettyに比べると格段に遅くなっています。GCログを見ても、マイナーGCの頻発、ConcurrentMarkSweepGCも頻発するなど、ヒープメモリの使用量がJettyに比べて多いことが見て取れます。

Tomcat GCログ

　アプリケーション実装時の注意点でも書いていますが、内部で利用するBufferのサイズが影響していることが考えられますので、大量のクライアントが接続してメッセージを送ってくる場合はヒープサイズを大きめに取る対処が必要と考えられます。

　最後にNode.jsですが、2回遅くなっている個所が見受けられますが、それ以外はJettyと同じとなっています。

テストケース【3】大量データ受信パターン

大量データ送信結果（その1）

大量データ送信結果（その2）

　大量データの送信については、それほど大きな差はないと想定していました。

　結果的には、「大量データ送信結果（その1）」を見て分かる通り、Jettyのデフォルトバッファサイズの小ささから送信効率の悪さを露呈する結果となっています。これに対して、Jettyの送信バッファサイズを2Mbytesに変更した場合は、「大量データ送信結果（その2）」の通り、Tomcatと同等の結果となっています。

　参考までにテキストデータを送信した場合のグラフを「大量データ送信（テキストデータ）」として掲載していますが、この場合デフォルトの場合、バッファサイズを拡張した場合とでTomcat／Jettyともに同じ傾向を示しています。

大量データ送信（テキストデータ）

コミュニティへ報告・相談することで解決につながるかも

　このように、Tomcatは多数のクライアントと接続した場合のメモリ使用量、Jettyは大量データ送信時の送信バッファサイズ、Node.jsはバイナリデータが送受信できない、などサーバごとに得手・不得手があります。各製品ともに、実際の導入に際しては十分な調査・検証を行うことをお勧めします。

　今回紹介した製品はオープンソースですので、問題を発見した場合や分からないことがあった場合などは、コミュニティへ報告・相談することで解決につながるかもしれませんので活用してみてはいかがでしょうか。その際、英語は必要ですが簡単な英語でも十分通じますので頑張ってみてください。