カーネル・モードで高速に動作するオープンソースのWebサーバー「TUX Web Server」（以下，TUX）の性能を，現在主流の「Apache」と比較した。静的コンテンツに大量のアクセスが集まる用途で，TUX 3.2はApache 2.0の1.57倍の性能を出した。OSが扱えるTCPコネクション数を増やす調整を施せば，標準設定時より性能が33％改善する。
「とにかくTUXは速い」（ユーザー同士のコミュニケーション・サイトを運営するNHN Japanの佐野裕ネットワーク&システム室長）---。米Red Hatが静的コンテンツの高速処理に主眼を置いて開発したオープンソースのWebサーバー・ソフト「TUX＊1」。このTUXが，現在主流の「Apache」と比較してどれだけ速いのかを検証した。
結論として，今回の検証環境ではTUXがApacheを大きく超える性能を示し，Apacheの1.57倍のリクエストを処理できた（図1[拡大表示]）。高速Webサーバー・ソフトとして知られるマイクロソフトの「Internet Information Services（IIS）6.0」に匹敵する性能である。TUXのパラメータ＊2は，同時1000ユーザー規模の大量アクセスを想定した初期設定になっているため，デフォルトのままでも十分な性能を示した。一方でApacheの性能を引き出すためには，パラメータの調整が必要だった。
6種類のWebサーバーを検証
実験環境は図2[拡大表示]の通り。Webサーバー機とWebクライアント機となる2台のPCをスイッチでつなぎ，Webクライアント機上でベンチマーク・ソフトを実行した。テストに使用したPCは，Webサーバー機として一般的なスペックのラックマウント型である。
検証したWebサーバー・ソフトは全6種で，オープンソースのTUX 2.2（2.2.7），TUX 3.2（3.2.16），Apache 1.3（1.3.31），Apache 2.0（2.0.50）に加え，商用ソフトの参考値としてIIS 5.0，IIS 6.0を計測した。TUXとApacheを動作させるOSとしては，Red Hat Linux 9.0とその後継OSであるFedora Core 2.0を用いた。
Apache 2.0のコンパイル時オプションは標準設定のままとした＊3。具体的には，スレッドを用いず，Apache 1.3同様にプロセスが処理を受け持つモデルを選んだ。
ベンチマーク・ソフトは，Apacheに付属する「ApacheBench」（コマンド名はab）である（画面1[拡大表示]）。シンプルなコマンド・ベースのツールであり，簡単に利用できる。同時接続TCPコネクション数，発行するリクエスト数，アクセスするWebページのURLを引数として指定すれば，テストに要した総時間，1秒当たりのリクエスト処理数，コネクションの確立に要する時間などを得られる。
なお，今回の実験モデルは，TUXの主用途である「静的コンテンツに対する同時1000ユーザー規模の大量アクセス」をシミュレートした。この実験モデルでは，Webサイトのトップ・ページや商品画像のダウンロード・サーバーのように，HTTPによる純粋なファイル転送性能が結果を左右する。アプリケーション・サーバーのフロントエンドとしてWebサーバーを利用する場合の性能を見るものではない。
カーネル動作の高速サーバー
TUXが高速に動作する理由は，その実装方法にある（図3[拡大表示]）。TUXはLinuxカーネル（2.4以降）に対するパッチとして提供されており，カーネルに直接組み込んで使う。このため，TUXはIIS 6.0と同様に，OSのカーネル・モードで動作する。ユーザー・プロセスとして動作しているアプリケーション・プログラムと比べ，プロセスの切り替え時に生じるオーバーヘッドが少なくなる。
高速に動作する一方で，TUXの用途は限定されている。HTMLファイルや画像ファイルのような静的なコンテンツのHTTP転送に限って使うことを想定している。データの入力や動的なページ生成を伴うWebアプリケーションを実行する場合は，Apacheなど別のWebサーバーを併用する使い方が基本である＊4。例えば，TUXが80番ポートで全HTTPリクエストをいったん受け付け，PHPプログラムのようなWebアプリケーションを8080ポートで動作しているApacheへリダイレクトする使い方ができる。
IIS並みの処理性能を出す
今回のベンチマーク試験のうち，1秒当たりのリクエスト処理数を示したグラフが図4[拡大表示]である。標準設定時の処理性能と，パラメータを調整したチューニング後の数値を取った（チューニング内容の詳細は後述）。ただし，WindowsとIISの組み合わせはチューニングが不要と思われたため，標準設定時のデータをそのままチューニング後の値として掲載した＊5。
TUXとApacheの性能値を比べて言えることは，2つある。1つは，同じOSなら，ApacheよりTUXのほうが明らかに高性能であるという点。もう1つは，Apache，TUXにかかわらず，OSはRed Hat Linux 9.0を使うより，Fedora Core 2.0を用いた場合のほうが高性能だった点である。その結果，Fedora Core 2.0とTUX 3.2の組み合わせは，チューニングによってIIS 6.0に肉薄する数値を記録した。
Apacheの初期設定に問題
次々ページの図5[拡大表示]はTCPコネクションを確立するまでの時間を示したグラフである。リクエスト処理性能と同様に，標準設定時とチューニング後の数値を取った。IISの数値は，標準設定時の結果を参考値として掲載した。
TUXは，コネクション確立までの時間にバラツキが少ない。最小値と最大値の差が小さく，チューニングの影響も比較的小さい。この理由は，プロセス・モデルを用いず，カーネルが生成するスレッドでリクエストを処理しているためと思われる。
一方のApacheは，標準設定時に扱えるプロセス/スレッド数が圧倒的に少ないため，コネクションを確立する時間の最大値は3000ミリ秒を超えた。ただし，チューニング後のApacheは，最も悪い数値を出したRed Hat Linux 9.0とApache 2.0の組み合わせでも，64ミリ秒と安定する。
最大プロセス/スレッド数を変更
コネクション確立に要する最大値を減らすために，Apacheに施したチューニング内容は以下の通りである。
まず，クライアントと一度張ったTCPコネクションを複数のHTTPリクエストで使いまわす「Keep Alive」の設定を解除。次に，起動時のプロセス数を指定する「Start Servers」を5から32に，最大同時接続数を決める「Max Clients」の値を150から1000に増やした。また，アクセスがなくても待ち受け状態にしておくプロセスの数「Min Spare Servers」を5から32に，待ち受け状態のプロセス数の上限である「Max Spare Servers」を10から256に増強した。
TUXとIISは標準設定のままでも特に問題ないと判断し，プロセス/スレッド数などに関するチューニングは実施しなかった。
TCPコネクションの飽和を防ぐ
Apacheに関するプロセス/スレッド数の調整のほかに，ApacheとTUXに共通するチューニング項目として，TCPコネクション数を増やす設定変更をOSに施した。OSの標準設定がボトルネックにならないようにするためである。
基本的に，Linuxが使うポート番号の範囲は，設定ファイル「/proc/sys/net/ipv4/ip_local_port_range」に記述する＊6。今回，Red Hat Linux 9.0とFedora Core 2.0は標準設定で3万2768から6万1000までの3万近いポート番号を使用可能であったため，この設定ファイルは変更しなかった。
その代わり，TCPコネクションのTIME_WAITとFIN_WAIT2の保持時間を調整した。TIME_WAITとは，TCPコネクションを閉じる際の制御パケットが消失するリスクに備えるため，一定時間待ち受け状態になることを指す。一方，FIN_WAIT2とは，最初に送ったFINに対するACKを受信した状態のことであり，この後に相手からのFIN要求を受信してそれに対するACKを返すとTIME_WAIT状態へ遷移する。
未使用のまま解放されないコネクションは特定のポート番号を消費し続け，利用可能なポート番号がすべて消費され尽くすと，ポートのどれかが解放されるまで新しいコネクションを確立できなくなる。安全のためには標準設定のまま運用すべきだが，大量アクセス時の性能は落ち込む。
今回のチューニングでは，TIME_WAIT状態にあるコネクションを高速にリサイクルできるようにしたほか＊7，FIN_WAIT2保持時間を標準設定の60秒から30秒へと短くした＊8。
これらのチューニングによって，図4[拡大表示]に示した1秒当たりのリクエスト処理数を大幅に増やすことができた。例えばTUX 3.2とFedora Core 2.0の組み合わせでは，標準設定時の7163.3からチューニング後の9505.7へ，1.33倍に性能が向上した。
テスターからの一言標準設定時でもチューニング時でも，TUXのリクエスト処理性能は常にApacheよりも優秀だった。TUXのみに注目した場合でも，TUXのバージョンアップやOSのチューニングによって，それぞれパフォーマンスが向上することを確認できた。また，プラットフォームとなるOSでは，Fedora Core 2.0（カーネル2.6）の成績がRed Hat Linux 9.0（同2.4）を常時上回った。 Red Hat Linuxがフリーではなくなった今，Fedora CoreとTUXの組み合わせで高いパフォーマンスを実証できたことは大きな意味を持つ。ぜひ読者の方々にも，Fedora CoreとTUXでの運用を試していただきたい。 今回検証を進める中でFedora CoreとTUXの動きが一番安定しており，体感でもとても速く感じた。実際の計測データと体感速度が一致するような優れた結果を得られたことはうれしい。今回の調査に携わったことを幸いに思う。 IISの性能はさすがだった。今回検証したデータの通り，その他のすべてのWebサーバーに対して，IIS 6.0のパフォーマンスが上回るという結果を得た。IIS 5.0とIIS 6.0の比較では約1.5～2倍程度のパフォーマンス向上が見られ，これはIIS 6.0の製品紹介にうたわれている通りの内容だった。 検証結果だけを見ると，調査時間に限りがあり，細部まで突っ込んだ調査とは言い難い。だが次の機会には，この検証を基にして弊社でもより多くのパターンを検証し，運用の目的に合ったシステム構築を目指したいと思う。 |
本文の最終3段落で，パラメータ・チューニングの対象となるTCPステートとして，TIME_WAITとFIN_WAIT2を取り違えていました。また，TUXの初出表記を，正式名称であるTUX Web Serverに修正します。以上，お詫びして訂正します。本文は修正済みです。[2008/11/06 19:00]
