ChangeLog
メール版
登録

ChangeLog

ウェブサーバベンチマーク「Apache／Linux vs IIS／NT」

Mixed Double
Linux and NT as Web Server on the Test Bed

Jurgen Schmidt 氏

Jurgen Schmidt 氏と独 c't マガジンに特別に許可を得て翻訳させていただきました。 原文記事（英語） Danke, Jurgen! Copyright C't Magazine (Verlag Heinz Heise)

※ c't マガジン … 独 Heise 社が発行する紙媒体の隔週刊のコンピュータ業界誌。 1983 年に創刊され、現在毎号35万部を発行。 読者層は主にプロ（及びプロ並の方々）。 一部の記事はオンラインでも閲覧可能であり、 また、一部の記事は英語に翻訳される。

※とりあえず概略です。 もう少し日本語で補足する予定ですが、詳細は原文記事（英語）をご覧下さい。

概要

• サーバに関する、Linux vs NT のベンチマークは、いくつかあります。

• しかし大抵は、記録を破り、ニュースの見出しを飾るために、非現実的なシナリオでベンチマークを行おうとする傾向にあります。

• c't マガジンのテストラボでは、現実指向の題材に焦点を当て、NT/IIS vs Linux/Apache の比較を行いました。

Siemens Primergy 870 （S.u.S.E. Linux 6.1／Windows NT 4.0. ）

※ウェブサーバに関するテストです。
※以下のグラフは、クリックして詳細をご覧になれます。

テスト1

• 100MBps の NIC 一つ。
• CPU 一つ。
  （CPU の処理能力をそれほど必要としない処理なので、複数の場合も同様の結果を得た。）
• 静的な特定の一つのHTML ページを集中的に要求。
• 結果

  ファイルサイズが 4KB の場合には、IIS/NT と Linux/Apache とで大差なし。 ファイルサイズが 8KB の場合には、Linux/Apache が僅かに IIS/NT より良い。

テスト2

（テスト1との違い）
• 4KB の 10,000 個（1万個）のファイルからランダムに要求。
• 高々総容量 40MB のファイルなので十分にバッファキャッシュに収まる。
• 結果

  （上の 2本）

  基本的にはテスト1の結果と同じ。 Linux の方がややより良くなった。（最終的に Linux の方が NT より 15％ほど良い。）

テスト3

• 4KB の 1,000,000 個（100万個）のファイルからランダムに要求。
• 2GB のメインメモリの二倍の大きさなので（ディスク）ファイル入出力が重要な役割を果たす。
• 結果

  （下の 2本）

  NT は 30rps (requests per second) 前後でウロウロ。 Linux は、166 rps 以上を記録。 512 クライアント時には、274 rps を記録。

テスト4

• 動的な HTML ページ （Perl/CGI）のテスト。

  ※ NT の人は、普通は ASP や VBScript を好むでしょうから、 これは NT 上の Perl/CGI がどの程度使えるか、 NT 上で Perl/CGI を利用したらどの程度のパフォーマンスが 得られるかというように解釈すべきテストであり、 システムとしての適切な比較では「ない」ことに注意してください。

• 結果

  NT、Linux 共に、1 CPU よりも 4 CPU の方が 2倍前後のパフォーマンスを記録。 NT の 4 CPU は、Linux の 1 CPU の約半分のパフォーマンス。 Linux にはチューニングを必要とした。 256 クライアント以上では NT は正常にレスポンスを返すより、エラーの方が多かった。

テスト5

• （イントラネットでなくインターネットのように）クライアントのコネクションが遅い場合、あるいは、データベースのクエリーのように時間を消費する場合、をシミュレート。
• sleep(3) をして、3秒の遅延を作る。
  （リクエスト自体は、次第にムラなく発行されるようになる。）
• 3秒間休止状態のプロセスは、CPU 時間はほとんど消費しないが、メモリやファイルハンドルやサーバプロセスといったリソースを消費。
• 結果

  Linux。クライアントの数に応じて線形に rps は伸びるが、（テストした負荷の範囲では）CPU を追加することのメリットは得られず。 NT は、7 rps 以上は処理できず。 IIS の設計（thread）が仇（あだ）となった？（このテストのような設定ではむしろ不利に働く。）

テスト6

• NIC ２つ。
• 結果

  Linux、NT 共に SMP の恩恵は受けられるが、 SMP/Linux は、1 CPU の NT に及ばず。 NT は NIC を増やせば、その分、まだパフォーマンスは上がりそう。 メモリ（キャッシュ）から静的な HTML ページを、100Mbps の NIC 複数本を必要とするスピードで転送したい方は、NT をどうぞ。

結論

2枚の NIC （ネットワークインターフェースカード）でテストした際には、 Linux は比較的かなり悪い結果を出しました。 このことは、Mindcraft の結果が 極めて現実的（起り得ること）だということを示しています。 NT＋IIS 側のルール（2枚の NIC を用いるというテストでの状況設定）に従う限り、 NT＋IIS は、そのフリーな競争相手よりも 明らかに優れていることになります。

もう一度、分かりやすく言い直しますと、 これらの結果は、1000リクエスト／秒以上の負荷に対応するものです。 ちなみに、 Heise 社（c't マガジンの出版社）のサーバは、 ピーク時でも 100 リクエスト／秒程度です。 また、今お話しているのは、 純粋に静的なページについて議論しているということに注意してください。 それらはシステムのメインメモリ内（のキャッシュ）に既に存在しているものです。 このテストが示しているのは、 Mindcraft の結果が （洗練されたサイトでは、ほとんどあらゆるサイトで一般的になっているような） 主に動的なコンテンツを取り扱う状況下にも、 そのまま当てはまるわけではないということです。

SMP モードでは、 Linux はまだ明らかに弱さを提示しています。 カーネル開発者自身も、 負荷の主な部分がカーネル自身にかけられた場合 （ユーザロードでなくシステムロードの場合）、 SMP モードではスケーラビリティの問題があることを大っぴらに認めています。 しかし、CGI スクリプトのように、 ユーザモードのタスクが同じように関わっている場合には、 Linux もプロセッサの追加により性能の向上を得ることができるます。 現在、 これらの SMP 問題に焦点を当て、 多くの開発努力が費やされています。

ウェブサーバの最も実用的な分野では、 既に Linux と Apache は少なくとも一歩は先んじていると言えます。 ページがシステムのメインメモリから直接配信されない場合には、 Linux と Apache にとって有利にさえ働いてしまいます。 この場合には、 オープンソース運動の極上の製品が、 レッドモンド産の商用競争相手を大きく引き離した性能を発揮します。

実用という点に関連して、 Mindcraft は、Linux と Apache はチューニングに関する情報を得るのが 難しいと評価していました。 もちろん、プロの Linux サポート体制は、まだ開発進行中であると言えます。 しかし、Apache と Linux 開発者は、格別に親切でした。 Microsoft 社から ListenBackLog についての情報を得るのに 1週間以上必要だったのに対し、 Linux と Apache の問題に関する我々の質問に対しては、 有効な情報が数時間で得られることができました。

各々のメーリングリストへメールを送ったら、 著しく性能を向上することできた、 特別なカーネルパッチまで得ることができました。 一方、 顧客の問題に特別に設計された NT のカーネルを提供してくれるような、 NT のサポート契約については、我々は聞いたことがありません。

関連 URL

ChangeLog

LWN コラム「Mindcraft 事件と Linux の今後」も是非ご覧下さい。