• BPnet
  • ビジネス
  • IT
  • テクノロジー
  • 医療
  • 建設・不動産
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版
  • PR

  • PR

  • PR

  • PR

  • PR

ITレポート(動向/解説)

オープンソースの高速Webサーバー「TUX」の実力

Apacheの1.57倍速い
TCPコネクション数の飽和に注意

日川 佳三=IT Pro 2005/11/16 日経SYSTEMS
出典:日経システム構築 2004年09月号92ページより
(記事は執筆時の情報に基づいており、現在では異なる場合があります)
目次一覧
図1●TUXの処理速度はApacheを上回る<BR>(a)同一条件下でTUX 3.2が1秒当たりに処理できるWebアクセスの数は,Apacheを57%上回り,IIS 6.0に匹敵する。(b)1000個のコネクションが同時発生する大量アクセスにおいても,TUXはコネクション確立にかかる時間が安定している。一方で標準設定のApacheでは,コネクションの確立にときどき長い時間を費やす場合があり,レスポンスにバラツキが出る
図1●TUXの処理速度はApacheを上回る<BR>(a)同一条件下でTUX 3.2が1秒当たりに処理できるWebアクセスの数は,Apacheを57%上回り,IIS 6.0に匹敵する。(b)1000個のコネクションが同時発生する大量アクセスにおいても,TUXはコネクション確立にかかる時間が安定している。一方で標準設定のApacheでは,コネクションの確立にときどき長い時間を費やす場合があり,レスポンスにバラツキが出る
[画像のクリックで拡大表示]
図2●実験環境&lt;BR&gt;2台のPCをそれぞれWebサーバー機,Webクライアント機とし,スイッチング・ハブでつないだ。4種類のOSと6種類のWebサーバー・ソフトを組み合わせて,Webアクセスの処理性能を計測した。ベンチマーク・ソフトはApacheBench。計測項目は,静的コンテンツの1秒当たりのダウンロード回数や,コネクションの確立に要する時間などである
図2●実験環境<BR>2台のPCをそれぞれWebサーバー機,Webクライアント機とし,スイッチング・ハブでつないだ。4種類のOSと6種類のWebサーバー・ソフトを組み合わせて,Webアクセスの処理性能を計測した。ベンチマーク・ソフトはApacheBench。計測項目は,静的コンテンツの1秒当たりのダウンロード回数や,コネクションの確立に要する時間などである
[画像のクリックで拡大表示]
画面1●ApacheBenchを使う&lt;BR&gt;実験に使ったベンチマーク・ソフトApacheBenchは,リクエスト数と同時コネクション数,WebページのURLを指定するだけで実行できる。ベンチマーク結果として,1秒当たりのリクエスト処理数,コネクションの確立までの時間などが得られる
画面1●ApacheBenchを使う<BR>実験に使ったベンチマーク・ソフトApacheBenchは,リクエスト数と同時コネクション数,WebページのURLを指定するだけで実行できる。ベンチマーク結果として,1秒当たりのリクエスト処理数,コネクションの確立までの時間などが得られる
[画像のクリックで拡大表示]
図3●TUXはカーネル・モードで高速に動作する&lt;BR&gt;TUXはLinuxカーネル2.4以降向けのOSパッチとして実装されており,カーネルの機能としてWebサーバーを実現する。別プロセスへの処理の切り替えが不要になるため,高速に動作する。また,カーネル内部にあるファイル・システムのキャッシュに直接アクセスできるため,ディスク入出力も高速になる
図3●TUXはカーネル・モードで高速に動作する<BR>TUXはLinuxカーネル2.4以降向けのOSパッチとして実装されており,カーネルの機能としてWebサーバーを実現する。別プロセスへの処理の切り替えが不要になるため,高速に動作する。また,カーネル内部にあるファイル・システムのキャッシュに直接アクセスできるため,ディスク入出力も高速になる
[画像のクリックで拡大表示]
図4●プラットフォームの差異による,1秒当たりのリクエスト処理数&lt;BR&gt;標準設定時,Fedora Core 2.0上で,TUX 3.2のリクエスト処理数はApache 1.3の2.75倍,Apache 2.0の2.87倍に達する。一方でTUX 3.2はWindows 2000 Server上のIIS 5.0の性能に匹敵するが,Windows Server 2003,Web EditionとIIS 6.0を組み合わせた場合の69%の性能でしかない。ただし,OSとWebサーバーにチューニングを施すと,TUX 3.2の性能はIIS 6.0の92%まで改善する。チューニング後はApache 1.3,Apache 2.0ともに性能が向上するが,TUX 3.2の優位性は変わらない
図4●プラットフォームの差異による,1秒当たりのリクエスト処理数<BR>標準設定時,Fedora Core 2.0上で,TUX 3.2のリクエスト処理数はApache 1.3の2.75倍,Apache 2.0の2.87倍に達する。一方でTUX 3.2はWindows 2000 Server上のIIS 5.0の性能に匹敵するが,Windows Server 2003,Web EditionとIIS 6.0を組み合わせた場合の69%の性能でしかない。ただし,OSとWebサーバーにチューニングを施すと,TUX 3.2の性能はIIS 6.0の92%まで改善する。チューニング後はApache 1.3,Apache 2.0ともに性能が向上するが,TUX 3.2の優位性は変わらない
[画像のクリックで拡大表示]
図5●プラットフォームの違いによる,コネクション確立の所要時間の差異&lt;BR&gt;TCPコネクションが確立するまでの時間を調べた。TUX 3.2はチューニング前後の数値にそれほど大きな違いはなく,比較的安定している。一方でApacheは標準設定時に扱えるプロセス/スレッド数が小さいため,Fedora Core 2.0とApache 2.0の組み合わせにおいてコネクション確立に要した最大時間が3009ミリ秒に達した。チューニングによって扱えるコネクション数を増やしたApacheでは,コネクション確立までの平均時間と最大時間が,いずれもTUX 3.2の性能をしのいでいる
図5●プラットフォームの違いによる,コネクション確立の所要時間の差異<BR>TCPコネクションが確立するまでの時間を調べた。TUX 3.2はチューニング前後の数値にそれほど大きな違いはなく,比較的安定している。一方でApacheは標準設定時に扱えるプロセス/スレッド数が小さいため,Fedora Core 2.0とApache 2.0の組み合わせにおいてコネクション確立に要した最大時間が3009ミリ秒に達した。チューニングによって扱えるコネクション数を増やしたApacheでは,コネクション確立までの平均時間と最大時間が,いずれもTUX 3.2の性能をしのいでいる
[画像のクリックで拡大表示]

カーネル・モードで高速に動作するオープンソースの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倍に性能が向上した。

NHN Japan ネットワーク&システム室の佐野裕室長(写真左)と,実際にテストを担当した武川陽一氏(写真右)

テスターからの一言

 標準設定時でもチューニング時でも,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]

あなたにお薦め

連載新着

連載目次を見る

今のおすすめ記事

  • 【IoTで快適オフィス】

    会社でトイレ難民、救世主はIoT

     IoTの技術を活用して、オフィス設備を社員が効率的に利用できる新サービスが相次いでいる。会議室やトイレの最新の空き状況がスマートフォンやPCで分かり、データ分析を通じて設備の配置などの最適化につなげる。IoTがオフィスの身近な悩みを解決し、快適な働き方につながる技術としても注目を集め始めた。

  • 【記者の眼】

    専有クラウドはいずれ沈む泥舟

     「ホステッドプライベートクラウド」「プライベートクラウド・アズ・ア・サービス」など呼び方はいくつもあるが、サーバーを1社で専有する専有クラウドの市場が拡大している。国内ではパブリッククラウドを上回るとの予想もある専有クラウドだが、はたして本当に成長するのだろうか。

ITpro SPECIALPR

What’s New!

経営

アプリケーション/DB/ミドルウエア

クラウド

運用管理

設計/開発

サーバー/ストレージ

クライアント/OA機器

ネットワーク/通信サービス

セキュリティ

もっと見る