TUXのベンチマーク記事
カーネル・モードで高速に動作するオープンソースのWebサーバー「TUX」の性能を，現在主流の「Apache」と比較した。静的コンテンツに大量のアクセスが集まる用途で，TUX 3.2はApache 2.0の1.57倍の性能を出した。OSが扱えるTCPコネクション数を増やす調整を施せば，標準設定時より性能が33％改善する。
カーネルモードで動作するウェブサーバー TUX、ということで久しぶりにこの名前を聞きました。3, 4 年前に Linux Magazine のムックか何かで特集されていたのを思い出します。その後あまり話を聞かなかったので TUX プロジェクトは頓挫したのかなと思いきや、それは僕の勘違いで、ちゃんとプロジェクトは動いていて成果が出ているということなのかも。
この記事ではベンチマークの比較対象として Apache が選ばれているけど、Apache よりも高速な実装は世の中に結構あって、たとえば Zeus とか IIS とか iPlanet などの商用のもの、それから esehttpd や lighttpd などのオープンソースかつフリーなもの、なんていうのがその具体例。個人的には TUX vs lighttpd でスタティックなコンテンツに対するベンチ結果を見たかったりする。
ところで、記事の中でいくつか言及したい点もあり。
この実験モデルでは，Webサイトのトップ・ページや商品画像のダウンロード・サーバーのように，HTTPによる純粋なファイル転送性能が結果を左右する。アプリケーション・サーバーのフロントエンドとしてWebサーバーを利用する場合の性能を見るものではない。
「アプリケーション・サーバーのフロントエンド」というのが何を指すのか曖昧なのですが、Reverse Proxy や、J2EE でサーブレットコンテナの手前に置くウェブサーバーみたいなものを指すとすると、この説明がちょっとよくわからず。フロントエンドっていったらおそらくそのことなんだと思うけど。
後半に、TUX はスタティックなコンテンツをさばくためのもので、動的なコンテンツにはアプリケーションサーバを別途動かして.... みたいなことが後半にかかれているので、typo か書き間違いかそんな感じですね。
コネクション確立に要する最大値を減らすために，Apacheに施したチューニング内容は以下の通りである。
まず，クライアントと一度張ったTCPコネクションを複数のHTTPリクエストで使いまわす「Keep Alive」の設定を解除。次に，起動時のプロセス数を指定する「Start Servers」を5から32に，最大同時接続数を決める「Max Clients」の値を150から1000に増やした。また，アクセスがなくても待ち受け状態にしておくプロセスの数「Min Spare Servers」を5から32に，待ち受け状態のプロセス数の上限である「Max Spare Servers」を10から256に増強した。
このベンチマークは 同時1,000 クライアントで一気にリクエストを投げることを想定しているので、Apache の MaxClients を 1,000 に増やすことでベンチ結果が良くなるというのは理解できます。あと、MaxClients が少ない環境で 1,000 リクエストを同時に投げるにあたって、KeepAlive を Off にすれば、prefork なプロセスが一つのリクエストに対して占有される時間が少なくなるので、その分結果がよくなるというのも分かります。
ただ、実際の運用を考えるとスタティックなコンテンツを返却する専用のサーバーで KeepAlive が Off になってるっていうのはあり得ない(モバイル用サーバとかは別) なので、このチューニングの仕方は間違いじゃないかと思います。KeepAlive が Off だとサーバーから見たベンチの結果は良くなっても、単一のクライアントから見たパフォーマンスが下がってしまう。MaxClients をメモリの許すぎりぎりまで増やし、且つ KeepAlive は On、加えて KeepAlive Timeout を短めに設定する、というのが正解かと思います。
LinuxのTIME_WAIT値は標準で60であり，これはTIME_WAIT状態が60秒間続くことを意味する。今回のチューニングでは，標準設定値の60を30に書き換え，TIME_WAIT状態を30秒で解放するようにした＊7。
/proc/sys/net/ipv4/tcp_fin_timeout をいじることで TCP の TIME_WAIT 時間を減らせるのは初めて知りました。これは是非試してみたい。
2005年11月17日追記
なんか TUX は下げ進行らしい。(http://nnri.dip.jp/~yf/momoka.cgi?op=readmsg&address=735)
