特集
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完全ガイド |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|