Jettyのバルクデータ転送性能

Hadoopで内部的にも使われているHTTPサーバJettyの性能を測ってみた。HDFSのブロックサイズは64MBだったと思うので、まずは64MBのファイルをwgetで取得した際のスループットを測った（ちなみにGFSのチャンクのことをHDFSではブロックと呼ぶ）。比較対象としてC言語で実装されたApacheとlighttpdでも同様の実験を行った。なお、ネットワークはGbEで、Iperfで941 Mbps出ることを確認している。Jettyのバージョンは6.1（Hadoop0.19.1に同梱されていのは5.1.4）、ApacheはCentOS標準の2.2.3、lighttpdは1.4.22。

その結果、共に896Mbpsと遜色ない値を示した。

さらに（現実的なシナリオとは言えないけど）ファイルサイズを1GBにしてみた。今回のサーバは1GBのメモリしか積んでないので、ファイル全体がメモリに載らず、性能はディスクで律速するはずである。結果はややばらついたので、それぞれ5回実行した結果を下表に示す。単位はMbps。

	1	2	3	4	5
Jetty 6.1	380.8	416.0	395.2	380.0	404.8
Apache 2.2.3	262.4	264.8	263.2	256.0	252.0
lighttpd 1.4.22	251.2	244.0	252.8	248.8	250.4

意外なことにJettyが勝っている。いったい何が影響しているのだろうか？特に設定ファイルはいじっていない。ディスクキャッシュの影響かなぁ。よくわからない。

実験をやった後に知ったのだけど、ブロックの転送にHTTPは使われてなさそうで、JettyはJobTrackerのモニタリング機能のために使われているようだ。DataNodeとHDFSクライアント間の通信はTCP/IP通信で、データは64KBのパケットに分割されてから送信される。パケットは512バイトごとにチェックサムが計算される。そもそも、（絶対条件ではないが基本的に）データが存在するノードでタスクが実行されるので、リモートノードと通信は起きないはずだ。

参考までに両者の輻輳ウィンドウの挙動を、TCP Probeモジュールを使って確認してみた。通信開始時は両者に違いがないように見えるが、観測したスループットはこの時点ですでに差がついているんだよな。Linuxカーネルのバージョンは2.6.18で、TCPはBIC（ssthreshの初期値は100）を使っている。TCP関連のパラメータはOSでフォルト設定から特にいじってない。


余談。JettyのコンパイルにはMavenが必要で、デフォルト設定だとビルド時にヒープが足りなくなるので、環境変数MAVEN_OPTSに-Xmx128mなどと指定する必要があった。