特集 Windows Server 2003完全ガイド
IIS 6.0のパフォーマンスを検証する

1.IIS 6.0の基礎知識

デジタルアドバンテージ
2003/06/26

 ベンチマーク・テストに進む前に、テスト結果を考察するための基礎知識として、従来のIIS 5.0(Windows 2000に付属)と新しいIIS 6.0(Windows Server 2003に付属)の内部構成の違いについて触れておこう。

IIS 5.0のプロセス・モデル

 Windows 2000に付属するIIS 5.0の内部構成を図示すると次のようになる。

IIS 5.0のプロセス・モデル
IIS 5.0では、INETINFO.EXEという実行プログラムが、HTTPの送受信を含め、Webサーバとしてのほとんどの処理を行う。これは通常のアプリケーションなので、OSの内部的には、ほかのプリケーションと同様にユーザー・モードで実行される。

 このようにIIS 5.0では、INETINFO.EXEという名前のプログラムが、WebアプリケーションのホスティングからISAPIフィルタ(Webアプリケーションで行う処理の前処理や後処理を実行するDLL)、構成情報の管理、HTTPの送受信に至るまで、Webサーバとしてのほとんどの処理を実行する。ただしINETINFO.EXEの内部でWebアプリケーションを実行した場合、万一アプリケーションが障害を起こすと、IIS全体がクラッシュしてしまうという問題がある。これを回避するため、ほとんどの場合は、外部コンポーネント(図中ではDLLHost.EXEとしている)を用意し、この内部でアプリケーションを実行するのが一般的であった。ただしこの場合でも、DLLHost.EXEの中で実行できるのはWebアプリケーションの一部だけであり、Webアプリケーション同士が完全に分離されるわけではなかった。

IIS 6.0のプロセス・モデル

 これに対しIIS 6.0では、Webサーバとしての可用性や性能を向上するために、プロセス・モデルが一新された。

IIS 6.0のプロセス・モデル
IIS 6.0ではまず、HTTPの送受信を行うコンポーネント(HTTP.SYS)がカーネル・モードで実行されるようになった。また各アプリケーションは、「ワーカー・プロセス」の内部で実行され、異なるWebアプリケーションはそれぞれ独立した「アプリケーション・プール」の中で実行される。

 まず注目すべき点は、Webサーバの処理として負荷の高いHTTPの送受信機能がHTTP.SYSとして分離され、これがカーネル・モードで実行されるようになったことだ。カーネル・モードとユーザー・モード間でのモード遷移には多大なコストがかかる。IIS 5.0では、HTTPリクエストを受信して、それにレスポンスを返すために、コストの高いモード遷移を繰り返すことになる。これに対しIIS 6.0では、HTTP処理用のコンポーネントをカーネル・モードに移すことで、モード遷移を低減し、パフォーマンス向上を図っている。

 その昔、Windows NT 3.51からWindows NT 4.0のバージョンアップにおいて、ウィンドウ・マネージャやGDI(グラフィック描画用API)、ディスプレイ・ドライバの一部をユーザー・モードからカーネル・モードに移行させることで、グラフィックス描画性能を劇的に向上させたことがあった。まったく異なるコンポーネントではあるが、これと同じような効果をWebサーバで狙ったものと考えてよいだろう。

 図のWeb Administration Service(WAS)は、IISの構成情報の管理や、IIS 6.0上で実行されるアプリケーション、およびIISの状態監視を行うコンポーネントである。IIS 5.0では、これもINETINFO.EXEの内部に包含されていたが、独立したコンポーネントになった。

 そしてIIS 6.0の高可用性を実現するのがワーカー・プロセスとアプリケーション・プールである。

 図に示したとおり、IIS 6.0のデフォルト(ワーカー・プロセス分離モード)の状態では、各Webアプリケーションは、アプリケーション・プールと呼ばれる独立した単位で実行される。Webサーバとしてのリクエストを受け付けるリクエスト・キューは、このアプリケーション・プールごとに割り当てられており、カーネル・モードのHTTP.SYSは、要求を受け付けると、それを適当なアプリケーション・プールのリクエスト・キューに入れる。

 アプリケーション・プールの中には、少なくとも1つのワーカー・プロセスがあり、WebアプリケーションやISAPIフィルタはこのワーカー・プロセス内部で実行される。ワーカー・プロセスは、独立したプロセスで(W3WP.EXE)である。

 IIS 6.0では、アプリケーションがアプリケーション・プールとワーカー・プロセスによって完全に分離されている。従っていずれかのアプリケーションがクラッシュして停止してしまった場合でも、ほかのアプリケーション・プールやワーカー・プロセスは影響を受けることなく、処理を続行できる。

IIS 6.0のパフォーマンス向上のポイント(そのほか)

 そのほか、IIS 6.0のパフォーマンス向上に寄与しているポイントとしては、次のものがある。

■ASPテンプレート・キャッシュ
 新しいASP.NETではなく、従来のASPテクノロジを利用したサイトも、IIS 6.0に移行することで性能が向上する可能性がある。

 ASPファイルが実行されると、ASPエンジンによってこれがコンパイルされ、ASPテンプレートとしてキャッシュされる。そしてキャッシュされたASPファイルが再度要求された場合、ASPエンジンは、ASPファイルをロードする代わりに、キャッシュ内にあるASPテンプレートをロードする。これにより、ASPファイルを再コンパイルする時間を削減することが可能になる。

 このASPテンプレート・キャッシュ自体は、従来のIIS 5.0でも提供されていた。しかしIIS 5.0では、キャッシュされるのはメモリ上のみで、キャッシュがあふれると、古いキャッシュが自動的に消去されるようになっていた。このため多数のASPページを実行するようなサイトでは、ASPテンプレート・キャッシュが必ずしも有効に作用しない場合があった。

 これに対しIIS 6.0では、ASPテンプレート・キャッシュがメモリだけではなく、ディスク上にも保持されるように改良された。これにより、大量のASPファイルを含む大規模なサイトでも、ASPテンプレート・キャッシュを効率よく機能させられるようになっている。

■カーネル・キャッシング
 前挙は従来のASPテクノロジでのみ有効な機能だが、このカーネル・キャッシングは、IIS 6.0とASP.NETを組み合わせた場合のみに機能するものだ。

 IIS 6.0では、カーネル・モードで実行されるHTTP.SYSが管理するキャッシュが用意されている。従来のIIS 5.0において、動的な要求が発生すると、要求をカーネル・モードからユーザー・モード上のアプリケーションに通知して、応答を再生成しなければならなった。これに対しIIS 6.0では、動的な要求に対するキャッシュにあるときには、要求をユーザー・モードのアプリケーションに送ることなく、キャッシュの内容を使ってカーネル・モードから直接応答を返すようになっている。


 INDEX
  [特集] Windows Server 2003完全ガイド
  IIS 6.0のパフォーマンスを検証する
  1.IIS 6.0の基礎知識
    2.IIS 5.0/IIS 6.0ベンチマーク・テスト
    3.テスト1:Microsoft .NET Pet Shop
    4.テスト2:シンプルなASP/ASP.NET
    5.テスト3:静的なWebページ表示
 
目次ページへ  Windows Server 2003完全ガイド


Windows Server Insider フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Windows Server Insider 記事ランキング

本日 月間