IIS 10.0 のチューニング
Windows Server 2022 には、インターネット インフォメーション サービス (IIS) 10.0 が付属しています。 このサービスのプロセス モデルは、IIS 8.5 および IIS 7.0 と同様です。 カーネルモードの Web ドライバー (http.sys) が、HTTP 要求を受信してルーティングし、応答キャッシュからの応答を処理します。 ワーカー プロセスが URL サブスペースに登録されると、http.sys は適切なプロセス (またはアプリケーション プールの一連のプロセス) に要求をルーティングします。
HTTP.sys の役目は、接続の管理と要求の処理です。 要求は、HTTP.sys のキャッシュで処理されるか、ワーカー プロセスに渡されて処理されます。 ワーカー プロセスは複数構成可能であり、これによりコストを抑えながら分離性を実現できます。 要求の処理のしくみについては、次の図を参照してください。
HTTP.sys は応答キャッシュを備えています。 要求が応答キャッシュのエントリに一致した場合、HTTP.sys はキャッシュ応答をカーネル モードから直接送信します。 ASP.NET などの一部の Web アプリケーションは、任意の動的コンテンツをカーネルモードのキャッシュにキャッシュできるメカニズムを備えています。 http.sys で頻繁に要求されるファイルは、IIS 10.0 の静的ファイル ハンドラーによって自動的にキャッシュされます。
Web サーバーにはカーネルモードのコンポーネントとユーザーモードのコンポーネントがあるので、パフォーマンスを最適化するには、両方のコンポーネントをチューニングする必要があります。 そのため、特定のワークロードについて IIS 10.0 をチューニングする場合は、次のものを構成します。
HTTP.sys および関連するカーネルモード キャッシュ
ワーカー プロセスとユーザーモード IIS (アプリケーション プールの構成を含む)
パフォーマンスに影響する特定のチューニング パラメーター
以下のセクションでは、IIS 10.0 のカーネルモードおよびユーザーモードの要素を構成する方法について説明します。
カーネルモードの設定
HTTP.sys のパフォーマンス関連の設定は、キャッシュの管理と、接続および要求の管理の 2 種類に大別されます。 レジストリ設定はすべて、次のレジストリ エントリの下に格納されています。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters
注 HTTP サービスを既に実行中の場合、変更を有効にするために再起動が必要です。
キャッシュ管理の設定
HTTP.sys が備えている利点の 1 つが、カーネルモード キャッシュです。 カーネルモード キャッシュ内に応答が存在する場合、HTTP 要求の処理をカーネル モードだけで完結できます。これにより、要求の処理にかかる CPU コストを大幅に抑えられます。 ただし、IIS 10.0 のカーネルモード キャッシュは物理メモリに基づいているため、エントリのコストとしてメモリが占有されます。
キャッシュ内のエントリが役に立つのは、使用される場合のみです。 一方、エントリは、使用されるかどうかにかかわらず常に物理メモリを消費します。 使用可能なリソース (CPU と物理メモリ) およびワークロード要件を考慮して、エントリの有効期間に対するキャッシュ内の項目の有用性 (キャッシュの項目を利用することで得られるコスト削減効果) とそのコスト (占有される物理メモリ) を評価する必要があります。 HTTP.sys は、頻繁にアクセスされる有用な項目のみをキャッシュに保持しようとします。ただし、特定のワークロードに対して HTTP.sys をチューニングすることで、Web サーバーのパフォーマンスを高められます。
以下に、HTTP.sys のカーネルモード キャッシュで役立つ設定をいくつか示します。
UriEnableCache (既定値: 1)
0 以外の値を指定すると、カーネルモードでの応答とフラグメントのキャッシュが有効になります。 ほとんどのワークロードでは、キャッシュを有効にすることをおすすめします。 応答とフラグメントのキャッシュが非常に少ないと予想される場合は、キャッシュを無効にすることを検討してください。
UriMaxCacheMegabyteCount (既定値: 0)
カーネルモード キャッシュで使用可能なメモリの上限を指定する 0 以外の値。 既定値の 0 の場合、キャッシュで使用可能なメモリの量をシステムがによって自動的に調整されます。
注 サイズの指定は上限を設定するだけであり、設定された上限サイズまでキャッシュが拡張されないこともあります。
Â
UriMaxUriBytes (既定値: 262,144 バイト (256 KB))
カーネルモード キャッシュのエントリのサイズ上限です。 この値より大きい応答またはフラグメントはキャッシュされません。 メモリが十分にある場合は、この上限を増やすことを検討してください。 メモリが限られており、大きいエントリが存在すると小さなエントリが入る余地がなくなる場合は、この上限を下げると役に立つことがあります。
UriScavengerPeriod (既定値: 120 秒)
HTTP.sys キャッシュは定期的にスカベンジャーでスキャンされます。前のスカベンジャー スキャンからその次のスキャンまでの間にアクセスされていないエントリは削除されます。 スカベンジャーの間隔の値を高く設定すると、スカベンジャー スキャンの回数を抑えられます。 ただし、古くアクセス頻度の少ないエントリがキャッシュに残るようになるため、キャッシュ メモリの使用量が増加する可能性があります。 この間隔を短くしすぎると、スカベンジャー スキャンの頻度が大きくなり、フラッシュとキャッシュ チャーンの回数が多くなりすぎる可能性があります。
要求および接続の管理の設定
Windows Server 2022 では、接続は HTTP.sys によって自動的に管理されます。 次のレジストリ設定は使用されなくなりました。
MaxConnections
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\MaxConnectionsIdleConnectionsHighMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsHighMarkIdleConnectionsLowMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsLowMarkIdleListTrimmerPeriod
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleListTrimmerPeriodRequestBufferLookasideDepth
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\RequestBufferLookasideDepthInternalRequestLookasideDepth
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\InternalRequestLookasideDepth
ユーザーモードの設定
このセクションの設定は、IIS 10.0 ワーカー プロセスの動作に影響します。 これらの設定のほとんどは、次の XML 構成ファイルに記載されています。
%SystemRoot%\system32\inetsrv\config\applicationHost.config
これらを変更するには、Appcmd.exe、IIS 10.0 の管理コンソール、および PowerShell コマンドレットの WebAdministration または IISAdministration を使用します。 ほとんどの設定は自動的に検出されるので、IIS 10.0 ワーカー プロセスと Web アプリケーションサーバーを再起動する必要はありません。 applicationHost.config ファイルの詳細については、「ApplicationHost.config の概要」を参照してください。
NUMA ハードウェアに最適な CPU 設定
Windows Server 2016 以降の IIS 10.0 では、NUMA ハードウェアのパフォーマンスとスケーラビリティを高めるために、スレッド プールのスレッドに対する最適な CPU の自動割り当てがサポートされています。 この機能は既定で有効になっており、次のレジストリ キーを使用して構成できます。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\ThreadPoolUseIdealCpu
この機能が有効な場合、IIS スレッド マネージャーは、すべての NUMA ノードの全 CPU にわたって、現在の負荷に応じて IIS スレッド プールのスレッドを可能な限り均等に分散させます。 一般に、NUMA ハードウェアに対しては、この既定設定を変更しないことをおすすめします。
注 最適な CPU 設定は、「アプリケーション プールの CPU 設定」で説明されているワーカー プロセスの NUMA ノード割り当て設定 (numaNodeAssignment and numaNodeAffinityMode) とは異なります。 最適な CPU 設定が影響を及ぼすのは、IIS スレッド プールのスレッドの分散方法ですが、ワーカー プロセスの NUMA ノード割り当て設定は、ワーカー プロセスが開始される NUMA ノードを決定します。
ユーザーモード キャッシュの動作の設定
ここでは、IIS 10.0 のキャッシュ動作に影響する設定について説明します。 ユーザーモード キャッシュはモジュールとして実装されており、統合パイプラインで発生したグローバル キャッシュ イベントをリッスンします。 ユーザーモード キャッシュを完全に無効化するには、applicationHost.config の system.webServer/globalModules 構成セクションから FileCacheModule (cachfile.dll) モジュールを削除します。
system.webServer/caching
| 属性 | 説明 | Default |
|---|---|---|
| Enabled | False に設定すると、IIS のユーザーモード キャッシュが無効になります。 キャッシュ ヒット率が非常に小さい場合は、キャッシュ コード パスに関連するオーバーヘッドを回避するために、キャッシュを完全に無効にすることをおすすめします。 ユーザーモード キャッシュを無効にしても、カーネルモード キャッシュは無効になりません。 | True |
| enableKernelCache | False に設定すると、カーネルモード キャッシュが無効になります。 | True |
| maxCacheSize | IIS ユーザーモード キャッシュのサイズを、メガバイト単位で指定した値に制限します。 既定値は、使用可能なメモリに応じて IIS によって調整されます。 この値は、アクセス頻度の高いファイル一式のサイズと、RAM の量または IIS プロセスのアドレス空間との比較結果に基づいて、慎重に選択してください。 | 0 |
| maxResponseSize | キャッシュするファイルのサイズ上限を指定します。 実際の値は、データ セット内で最も大きいファイルの数およびサイズと、使用可能な RAM の関係から決まります。 サイズが大きく要求頻度が高いファイルをキャッシュすると、CPU 使用率、ディスク アクセス、関連する待ち時間を抑えられます。 | 262144 |
圧縮動作の設定
IIS 7.0 以降では、既定で静的コンテンツが圧縮されます。 また、DynamicCompressionModule がインストールされている場合、既定で動的コンテンツの圧縮も有効になります。 圧縮によって帯域幅の使用量は減少しますが、CPU 使用率は増加します。 圧縮されたコンテンツは、可能であればカーネルモード キャッシュにキャッシュされます。 IIS 8.5 以降では、静的コンテンツと動的コンテンツについて個別に圧縮を制御できます。 一般的な静的コンテンツは、GIF ファイルや HTM ファイルなどの変更されないコンテンツです。 一般的な動的コンテンツは、ASP.NET ページなどであり、サーバー上のスクリプトまたはコードにより生成されます。 任意の拡張機能の分類を、静的または動的としてカスタマイズできます。
圧縮を完全に無効にするには、applicationHost.config の system.webServer/globalModules セクションにあるモジュールの一覧から、StaticCompressionModule と DynamicCompressionModule を削除します。
system.webServer/httpCompression
| 属性 | 説明 | Default |
|---|---|---|
| staticCompression-EnableCpuUsage staticCompression-DisableCpuUsage dynamicCompression-EnableCpuUsage dynamicCompression-DisableCpuUsage |
指定した制限値を現在の CPU 使用率が超えた場合に圧縮を有効にするか、または下回った場合に圧縮を無効にします。 IIS 7.0 以降では、無効のしきい値を安定状態の CPU 使用率が超えた場合、圧縮は自動的に無効になります。 CPU 使用率が有効のしきい値を下回った場合、圧縮は有効になります。 |
50、100、50、90 |
| directory | 圧縮された静的ファイルを一時的に保存およびキャッシュするディレクトリを指定します。 このディレクトリへのアクセス頻度が高い場合は、ディレクトリをシステム外に移すことを検討してください。 | %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files |
| doDiskSpaceLimiting | すべての圧縮済みファイルで占有可能なディスク領域の容量について、制限を設けるかどうかを指定します。 圧縮されたファイルは、directory 属性で指定された圧縮ディレクトリに保存されます。 | True |
| maxDiskSpaceUsage | 圧縮ディレクトリのディスク領域のうち、圧縮されたファイルが占有できる容量をバイト単位で指定します。 圧縮されたコンテンツの合計サイズが大きすぎる場合、この設定値を増やす必要がある可能性があります。 |
100 MB |
system.webServer/urlCompression
| 属性 | 説明 | Default |
|---|---|---|
| doStaticCompression | 静的コンテンツを圧縮するかどうかを指定します。 | True |
| doDynamicCompression | 動的コンテンツを圧縮するかどうかを指定します。 | True |
注意
IIS 10.0 を実行しているサーバーの平均 CPU 使用率が低い場合は、特に応答が大きいのであれば、動的コンテンツの圧縮を有効にすることをおすすめします。 これは、まずテスト環境で実施し、ベースラインから CPU 使用率に対する影響を評価してください。
既定のドキュメント一覧のチューニング
既定のドキュメント モジュールは、ディレクトリのルートに対する HTTP 要求を処理し、特定のファイル (Default.htm や Index.htm など) への要求に変換します。 平均では、インターネット上の全要求のうち 25% 程度が、既定のドキュメント パスを通過します。 これは、サイトごとに大きく異なります。 HTTP 要求でファイル名が指定されていない場合、既定のドキュメント モジュールは、許可されている既定のドキュメントの一覧でファイル システム内の各名前を検索します。 特に、コンテンツにたどり着くためにネットワーク ラウンド トリップやディスク アクセスが必要な場合、これによってパフォーマンスが低下する可能性があります。
このようなオーバーヘッドは、既定のドキュメントを選択的に無効にするか、一覧のドキュメントを減らすか、ドキュメントの一覧を並べ替えることで回避できます。 Web サイトで既定のドキュメントを使用する場合は、一覧に含める既定のドキュメント タイプを、使用されるものだけにすることをおすすめします。 さらに、アクセス頻度が最も高い既定のドキュメントのファイル名が先頭になるように、一覧を並び替えます。
applicationHost.config の場所タグ内で構成をカスタマイズするか、コンテンツ ディレクトリに web.config ファイルを直接挿入することで、特定の URL に対する既定のドキュメント動作を選択的に設定できます。 これにより、必要な場合にのみ既定のドキュメントを有効にして、一覧には URL ごとの適切なファイル名を設定するというハイブリッド アプローチを実現できます。
既定のドキュメントを完全に無効にするには、applicationHost.config の system.webServer/globalModules セクションにあるモジュールの一覧から、DefaultDocumentModule を削除します。
system.webServer/defaultDocument
| 属性 | 説明 | Default |
|---|---|---|
| enabled | 既定のドキュメントを有効にするかどうかを指定します。 | True |
<files> 要素 |
既定のドキュメントとして設定するファイル名を指定します。 | 既定の一覧は Default.htm、Default.asp、Index.htm、Index.html、Iisstart.htm、Default.aspx です。 |
バイナリ集中ログ
サーバー セッションに URL グループが多数存在する場合、URL グループごとに特定の形式のログ ファイルを数百個作成し、ディスクにログ データを書き込むというプロセスによって、貴重な CPU やメモリ リソースがすぐに消費されてしまう可能性があります。これにより、パフォーマンスとスケーラビリティに問題が生じます。 バイナリ集中ログを使用することで、組織で必要とされる詳しいログ データを提供しながら、ログに使用するシステム リソースの量を最小限に抑えられます。 バイナリ形式のログを解析するには、後処理ツールが必要です。
バイナリ集中ログを有効にするには、centralLogFileMode 属性を CentralBinary に設定し、enabled 属性を True に設定します。 システム アクティビティとログ アクティビティとの競合を防ぐために、集中ログ ファイルの場所は、システム パーティションの外にある専用のログ ドライブに移すことをおすすめします。
system.applicationHost/log
| 属性 | 説明 | Default |
|---|---|---|
| centralLogFileMode | サーバーのログ モードを指定します。 バイナリ集中ログを有効にするには、この値を CentralBinary に変更します。 | サイト |
system.applicationHost/log/centralBinaryLogFile
| 属性 | 説明 | Default |
|---|---|---|
| enabled | バイナリ集中ログを有効にするかどうかを指定します。 | × |
| directory | ログ エントリの書き込み先となるディレクトリを指定します。 | %SystemDrive%\inetpub\logs\LogFiles |
アプリケーションとサイトのチューニング
アプリケーション プールとサイトのチューニングに関連する設定を次に示します。
system.applicationHost/applicationPools/applicationPoolDefaults
| 属性 | 説明 | Default |
|---|---|---|
| queueLength | HTTP.sys のアプリケーション プールのキューに登録する要求の数について、要求を拒否するまでの上限を指定します。 このプロパティの値を上回った場合、IIS は以降の要求を拒否し、503 エラーを返します。 503 エラーが検出された場合には、待ち時間が長いバックエンド データ ストアと通信するアプリケーションに対してこの値を増やすことをおすすめします。 |
1000 |
| enable32BitAppOnWin64 | True の場合、64 ビット プロセッサを搭載したコンピューターで 32 ビット アプリケーションを実行できます。 メモリ使用量が問題になっている場合、32 ビット モードを有効にすることを検討してください。 32 ビット アプリケーションは 64 ビット アプリケーションに比べてポインター サイズと命令サイズが小さいため、メモリ使用量を抑えられます。 64 ビット コンピューターで 32 ビット アプリケーションを実行する場合の欠点は、ユーザーモードのアドレス空間が 4 GB までに制限されていることです。 |
× |
system.applicationHost/sites/VirtualDirectoryDefault
| 属性 | 説明 | Default |
|---|---|---|
| allowSubDirConfig | IIS で、web.config ファイルの検索時に現在のレベルより低いコンテンツ ディレクトリ内も対象にするか (True)、web.config ファイルの検索時に現在のレベルより低いコンテンツ ディレクトリ内は対象にしないか (False) を指定します。 仮想ディレクトリ内の構成のみを許可するシンプルな制限を適用することで、/<name>.htm が仮想ディレクトリでない限り、構成ファイルを検索しないように IIS 10.0 を設定できます。 追加のファイル操作を省略することで、静的コンテンツへのランダム アクセスが非常に多い Web サイトのパフォーマンスを大幅に高めることができます。 | True |
IIS 10.0 モジュールの管理
IIS 10.0 は、モジュール構造をサポートするために、複数のユーザー拡張モジュールに分割されています。 この分割のコストはわずかです。 統合パイプラインでは、各モジュールについて、モジュールに関連するすべてのイベントに対してモジュールを呼び出す必要があります。 これは、モジュールで何らかの処理を実行する必要があるかどうかに関係なく発生します。 特定の Web サイトに関連しないモジュールをすべて削除することで、CPU サイクルとメモリを節約できます。
Web サーバーを単純な静的ファイル用にチューニングする場合は、UriCacheModule、HttpCacheModule、StaticFileModule、AnonymousAuthenticationModule、HttpLoggingModule の 5 つのモジュールだけを含めます。
applicationHost.config からモジュールを削除するには、system.webServer/globalModules のモジュール宣言を削除するだけでなく、system.webServer/handlers セクションおよび system.webServer/modules セクションのすべてのモジュール参照を削除します。
Classic ASP の設定
Classic ASP 要求の処理にかかる主なコストには、スクリプト エンジンの初期化、要求された ASP スクリプトの ASP テンプレートへのコンパイル、スクリプト エンジンでのテンプレートの実行などがあります。 テンプレートの実行コストは要求された ASP スクリプトの複雑さに依存しますが、IIS Classic ASP モジュールではスクリプト エンジンをメモリ内にキャッシュし、テンプレートをメモリとディスク (メモリ内のテンプレート キャッシュがオーバーフローした場合のみ) の両方にキャッシュして、CPU の制約が大きいシナリオのパフォーマンスを向上できます。
Classic ASP テンプレート キャッシュとスクリプト エンジンのキャッシュを構成するための設定を次に示します。これらは、ASP.NET の設定には影響しません。
system.webServer/asp/cache
| 属性 | 説明 | Default |
|---|---|---|
| diskTemplateCacheDirectory | メモリ内キャッシュのオーバーフロー時に ASP でコンパイル済みテンプレートを保存するために使用するディレクトリの名前です。 推奨事項: 使用頻度が低いディレクトリ (例: オペレーティング システムや IIS ログ、その他のアクセス頻度の高いコンテンツと共有されていないドライブ) を設定してください。 |
%SystemDrive%\inetpub\temp\ASP Compiled Templates |
| maxDiskTemplateCacheFiles | ディスクにキャッシュできるコンパイル済み ASP テンプレートの最大数を指定します。 推奨事項: 上限値である 0x7FFFFFFF に設定してください。 |
2000 |
| scriptFileCacheSize | この属性は、メモリ内にキャッシュできるコンパイル済み ASP テンプレートの最大数を指定します。 推奨事項: アプリケーション プールによって提供される要求頻度の高い ASP スクリプトの数以上に設定してください。 可能であれば、メモリ制限で許容される ASP テンプレート数に設定します。 |
500 |
| scriptEngineCacheMax | メモリ内にキャッシュされるスクリプト エンジンの最大数を指定します。 推奨事項: アプリケーション プールによって提供される要求頻度の高い ASP スクリプトの数以上に設定してください。 可能であれば、メモリ制限で許容されるスクリプト エンジン数に設定します。 |
250 |
system.webServer/asp/limits
| 属性 | 説明 | Default |
|---|---|---|
| processorThreadMax | ASP が作成できる 1 プロセッサあたりの最大ワーカー スレッド数を指定します。 現在の設定では負荷を処理しきれず、要求の処理中にエラーが発生するか、CPU リソースの使用率が低下している場合は、値を増やしてください。 | 25 |
system.webServer/asp/comPlus
| 属性 | 説明 | Default |
|---|---|---|
| executeInMta | IIS での ASP コンテンツの提供中にエラーまたは失敗が検出された場合は、True に設定します。 これは、複数の分離サイトをホストしており、各サイトでそれぞれのワーカー プロセスを実行している場合に発生することがあります。 通常、エラーは、イベント ビューアーの COM+ からレポートされます。 この設定により、ASP でマルチスレッド アパートメント モデルが有効になります。 | × |
ASP.NET のコンカレンシー設定
ASP.NET 3.5
ASP.NET の既定では、安定状態におけるサーバーのメモリ消費を抑えるために、要求のコンカレンシーが制限されています。 コンカレンシーが高いアプリケーションでは、全体のパフォーマンスを高めるために、いくつかの設定を調整する必要がある場合があります。 この設定は、aspnet.config ファイルで変更できます。
<system.web>
<applicationPool maxConcurrentRequestsPerCPU="5000"/>
</system.web>
システムのリソースを最大限に活用するには、以下の設定が役立ちます。
maxConcurrentRequestPerCpu (既定値: 5000)
この設定では、システムでコンカレントに実行可能な ASP.NET 要求の最大数を制限します。 ASP.NET アプリケーションのメモリ消費を抑えるために、既定値は控えめに設定されています。 長時間にわたり同期 I/O 操作を実行するアプリケーションが実行されるシステムでは、この制限値を増やすことをおすすめします。 既定の設定のままである場合、負荷が高くなると、キュー制限の超過が原因でキューまたは要求が失敗し、ユーザーの待ち時間が長くなる可能性があります。
ASP.NET 4.6
ASP.NET 4.7 には、maxConcurrentRequestPerCpu の設定に加えて、非同期操作に強く依存しているアプリケーションのパフォーマンスを向上させるための設定も用意されています。 この設定は aspnet.config ファイルで変更できます。
<system.web>
<applicationPool percentCpuLimit="90" percentCpuLimitMinActiveRequestPerCpu="100"/>
</system.web>
- percentCpuLimit (既定値: 90) 非同期要求には、このようなシナリオで (ハードウェアの容量を超える) 大きな負荷がかかった場合のスケーラビリティの問題があります。 この問題の原因は、非同期シナリオにおける割り当ての性質です。 このような状況では、割り当ては非同期操作の開始時に行われますが、使用されるのは操作の完了時です。 オブジェクトはその時点までに、非常に高い確率で、GC によって第 1 世代または第 2 世代に移動されています。 このような状況で負荷を大きくすると、ある時点までは 1 秒あたりの要求数 (RPS) が増加します。 その時点を過ぎる、GC 内で費やされる時間が問題になって RPS が低下し始め、スケーリングにマイナスの影響が生じます。 この問題を解決するために、CPU 使用率が percentCpuLimit の設定を超えると、要求は ASP.NET のネイティブ キューに送信されるようになります。
- percentCpuLimitMinActiveRequestPerCpu (既定値: 100) CPU 調整 (percentCpuLimit 設定) は、要求の数ではなくコストに基づいています。 そのため、CPU 使用率の高い要求が少量発生した場合、ネイティブ キューでバックアップされ、入力要求を除いてキューを空にできなくなります。 この問題を解決するには、percentCpuLimitMinActiveRequestPerCpu を使用して、調整開始までに処理する要求数の下限を設定します。
ワーカー プロセスとリサイクルのオプション
IIS ワーカー プロセスのリサイクルに関するオプションを構成することで、介入やサービスまたはコンピューターのリセットを行うことなく、深刻な状況やイベントに対して実用的なソリューションを提供できます。 このような状況やイベントには、メモリ リーク、メモリ負荷の増加、ワーカー プロセスの応答停止や動作停止があります。 通常の条件下では、リサイクル オプションは不要な場合があり、リサイクルを無効にするか、システムを構成してリサイクルの頻度を非常に高くすることができます。
特定のアプリケーションに対してプロセスのリサイクルを有効にするには、recycling/periodicRestart 要素に属性を追加します。 リサイクル イベントは、メモリ使用量、指定した要求数、指定した期間など、いくつかのイベントによってトリガーできます。 ワーカー プロセスのリサイクル時には、キューに登録済みの要求と実行中の要求がドレインされるのと同時に、新しい要求を処理する新しいプロセスが開始されます。 recycling/periodicRestart 要素はアプリケーション単位です。つまり、次の表の各属性は、アプリケーションごとにパーティション分割されます。
system.applicationHost/applicationPools/ApplicationPoolDefaults/recycling/periodicRestart
| 属性 | 説明 | Default |
|---|---|---|
| メモリ | 仮想メモリの使用量が指定の制限 (KB 単位) を超えた場合に、プロセスのリサイクルを有効にします。 これは、アドレス空間が 2 GB しかない 32 ビット コンピューターに便利な設定です。 メモリ不足エラーによって要求が失敗するのを防ぐうえで役立ちます。 | 0 |
| privateMemory | プライベート メモリの割り当て量が指定の制限 (KB 単位) を超えた場合に、プロセスのリサイクルを有効にします。 | 0 |
| requests | 要求数が指定した数を超えた場合に、プロセスのリサイクルを有効にします。 | 0 |
| time | 指定した期間が経過した場合に、プロセスのリサイクルを有効にします。 | 29:00:00 |
ワーカープロセスの動的ページアウトのチューニング
Windows Server 2012 R2 以降の IIS には、(IIS 7 から存在する終了オプションに加えて) しばらくの間アイドル状態になったワーカー プロセスを中断する構成オプションが用意されています。
アイドル状態のワーカー プロセスのページアウト機能と、アイドル状態のワーカー プロセスの終了機能はどちらも、サーバーのメモリ使用量を節約することが主な目的です。これは、サイトはただ存在してリッスンしているだけでも、大量のメモリを消費する可能性があるからです。 サイトで使用されているテクノロジ (静的コンテンツ、ASP.NET、または他のフレームワーク) にもよりますが、使用されるメモリの量は 10 MB 程度から数百 MB にまで及びます。つまり、サーバーに多数のサイトを構成している場合、サイトにとって最も有効な設定を特定することで、アクティブなサイトと中断済みサイトの両方のパフォーマンスを大幅に向上させることができます。
詳しい説明に移る前に、メモリの制約がないのであれば、サイトを中断および終了しないように設定することが最善の方法となる場合があることに注意してください。 いずれにしても、マシン上にワーカー プロセスしか存在しない場合、そのプロセスを終了する価値はほとんどありません。
Note
サイトで実行されているコードが、メモリ リークやその他の原因で不安定である場合、アイドル状態になったら終了するようにサイトを設定する方法が、コード バグの修正に代わる応急処置になる可能性があります。 これは推奨されるものではありませんが、緊急事態においては、恒常的な解決策を準備している間のクリーンアップ メカニズムとして、この機能を使用すると役立つ場合があります。
考慮すべきもう 1 つの要因は、ワーカー プロセスで使用されるデータをコンピューターがディスクに書き込む必要があるので、サイトのメモリ使用量が多いと、中断プロセス自体によって負担が生じることです。 ワーカー プロセスで大量のメモリが使用されている場合、バックアップが始まるまで待機するコストよりも、プロセスを中断するコストがの方が高い可能性があります。
ワーカー プロセスの中断機能を最大限に活用するには、各アプリケーション プール内のサイトを調査し、中断すべきサイト、終了すべきサイト、無期限にアクティブにしておくべきサイトを特定する必要があります。 操作とサイトのそれぞれについて、理想的なタイムアウト期間を把握する必要があります。
サイトについて、アクセスは毎日あるものの、常時アクティブにしておく必要があるほどのアクセス回数はないのであれば、中断または終了を構成することをおすすめします。 このようなサイトは、一般的には、1 日あたりの一意の訪問者数が 20 人程度かそれ以下のものです。 サイトのログ ファイルを使用してトラフィック パターンを分析し、1 日の平均トラフィックを計算できます。
特定のユーザーは通常、サイトに接続してからしばらくはその状態を維持し、追加の要求を行うので、1 日の要求数をカウントするだけでは、実際のトラフィック パターンが正確にわからない可能性があることに注意してください。 より正確な測定値を得るには、Microsoft Excel などのツールを使用して、要求間の平均時間を計算することをおすすめします。 例:
| 数値 | 要求 URL | 要求時刻 | 差分 |
|---|---|---|---|
| 1 | /SourceSilverLight/Geosource.web/grosource.html | 10:01 | |
| 2 | /SourceSilverLight/Geosource.web/sliverlight.js | 10:10 | 0:09 |
| 3 | /SourceSilverLight/Geosource.web/clientbin/geo/1.aspx | 10:11 | 0:01 |
| 4 | /lClientAccessPolicy.xml | 10:12 | 0:01 |
| 5 | / SourceSilverLight/GeosourcewebService/Service.asmx | 10:23 | 0:11 |
| 6 | / SourceSilverLight/Geosource.web/GeoSearchServer...¦. | 11:50 | 1:27 |
| 7 | /rest/Services/CachedServices/Silverlight_load_la...¦ | 12:50 | 1:00 |
| 8 | /rest/Services/CachedServices/Silverlight_basemap...¦. | 12:51 | 0:01 |
| 9 | /rest/Services/DynamicService/ Silverlight_basemap...¦. | 12:59 | 0:08 |
| 10 | /rest/Services/CachedServices/Ortho_2004_cache.as... | 13:40 | 0:41 |
| 11 | /rest/Services/CachedServices/Ortho_2005_cache.js | 13:40 | 0:00 |
| 12 | /rest/Services/CachedServices/OrthoBaseEngine.aspx | 13:41 | 0:01 |
ただし、どのような設定を適用すべきか特定するのは困難です。 この例では、サイトは複数のユーザーから多数の要求を受け取っており、上の表によれば、4 時間の間に一意のセッションが合計 4 つ発生しているとわかります。 アプリケーション プールのワーカー プロセス中断の既定設定では、サイトは、タイムアウト時間が既定値の 20 分を超えると終了されます。この場合、これらのユーザーは、サイトのスピンアップ サイクルの影響を受けます。 このサイトは、ほとんどの時間帯にわたってアイドル状態であり、中断すればリソースを節約できると共に、ユーザーがサイトにほぼ瞬時にアクセスできるようになるので、ワーカー プロセスを中断する候補として最適です。
最後に、非常に重要な点として、この機能はディスク パフォーマンスに大きく左右されます。 中断とウェイクアップのプロセスでは、大量のデータのハード ドライブへの書き込みと読み取りが発生するので、高速ディスクを使用することを強くおすすめします。 この機能には、ソリッド ステート ドライブ (SSD) が理想的であり、強く推奨されます。また、Windows ページ ファイルを SSD 上に保存するようにしてください (オペレーティング システム自体が SSD にインストールされいない場合は、ページ ファイルを SSD に移すようにオペレーティング システムを構成します)。
SSD を使用するかどうかにかかわらず、ファイルのサイズを変更することなくページアウト データを SSD に書き込めるように、ページ ファイルのサイズを固定することもお勧めします。 既定では、Windows は必要に応じて自動的にページ ファイルのサイズを調整するように構成されているため、オペレーティング システムのページ ファイルへのデータの保存時に必要であれば、ページファイルのサイズ変更が行われる可能性があります。 サイズを固定値に設定することで、サイズ変更を防止し、パフォーマンスを大幅に高められます。
事前に固定されたページ ファイル サイズを構成するには、中断するサイトの数とサイトで使用されるメモリの量に応じて、適切なサイズを計算する必要があります。 アクティブなワーカー プロセスの平均が 200 MB で、中断するサーバー上のサイト数が 500 個である場合は、ページ ファイルのサイズは、基本サイズに (200 * 500) MB を加えたものより大きくする必要があります (この例では 基本サイズ + 100 GB)。
注意
サイトを中断した場合、各サイトにつき約 6 MB が消費されます。今回の例では、すべてのサイトが中断された場合のメモリ使用量は約 3 GB になります。 ただし実際には、すべてのサイトが同時に中断されることはまずありません。
トランスポート層セキュリティのチューニング パラメーター
TLS (トランスポート層セキュリティ) を使用すると、追加の CPU コストが発生します。 TLS で最もコストがかかる部分は、セッションの確立です。これは、完全なハンドシェイクが必要であるからです。 さらに、このコストに、再接続、暗号化、暗号化の解除も加わります。 TLS のパフォーマンスを向上させるには、次の手順を実行します。
TLS セッションの HTTP キープアライブを有効にします。 これにより、セッション確立にかかるコストを排除できます。
特にキープアライブ以外のトラフィックについては、必要に応じてセッションを再利用します。
暗号化は、サイト全体ではなく、暗号化が必要なページまたはサイトの一部にのみ選択的に適用します。
注意
- キーを大きくするとセキュリティが高まりますが、CPU の使用時間も長くなります。
- 一部のコンポーネントは、暗号化が不要である場合があります。 ただし、プレーンな HTTP と HTTPS を混在させると、ページ上の一部のコンテンツがセキュリティで保護されていないことを示す警告が表示されることがあります。
Internet Server Application Programming Interface (ISAPI)
ISAPI アプリケーションでは、特別なチューニング パラメーターは必要ありません。 プライベートの ISAPI 拡張機能を作成する場合は、パフォーマンスとリソース使用を意識して作成するようにしてください。
マネージド コードのチューニングに関するガイドライン
IIS 10.0 の統合パイプライン モデルを使用すると、柔軟性と拡張性を高めることができます。 ネイティブ コードまたはマネージド コードで実装したカスタム モジュールを、パイプラインに挿入するか、既存のモジュールと置き換えられます。 この拡張モデルはシンプルで使いやすいものですが、グローバル イベントにフックする新しいマネージド モジュールを挿入する際には注意が必要です。 グローバル マネージド モジュールを追加するということは、静的ファイル要求を含むすべての要求でマネージド コードへのアクセスが必要になるということです。 カスタム モジュールは、ガベージ コレクションなどのイベントの影響を受けやすいモジュールです。 さらに、カスタム モジュールを使用すると、ネイティブ コードとマネージド コード間でのデータ マーシャリングが原因で CPU コストが大幅に増加します。 可能であれば、マネージド モジュールの preCondition を managedHandler に設定してください。
コールド スタートアップのパフォーマンスを向上させるには、ASP.NET Web サイトをプリコンパイルするか IIS のアプリケーション初期化機能を活用して、アプリケーションをウォームアップします。
セッション状態が不要な場合は、ページごとにオフにしてください。
I/O バインド操作が多数ある場合は、関連する API について、スケーラビリティに優れた非同期バージョンを使用することをおすすめします。
また、出力キャッシュを適切に利用することでも、Web サイトのパフォーマンスを高められます。
分離モード (サイト 1 つにつきアプリケーション プール 1 つ) で ASP.NET スクリプトが含まれるホストを複数実行する場合は、メモリ使用量を監視します。 サーバーでは、予想されるアプリケーション プールのコンカレント実行数に対して十分な RAM を確保してください。 複数の分離プロセスではなく、複数のアプリケーション ドメインを使用することを検討してください。
IIS のパフォーマンスに影響するその他の問題
IIS のパフォーマンスに影響する可能性がある問題を次に示します。
キャッシュに対応していないフィルターのインストール
HTTP キャッシュに対応していないフィルターをインストールすると、IIS のキャッシュが完全に無効になるため、パフォーマンスが低下します。 この動作は、IIS 6.0 より前に作成された ISAPI フィルターで発生する可能性があります。
Common Gateway Interface (CGI) 要求
パフォーマンス上の理由から、IIS では、要求の処理に CGI アプリケーションを使用することは推奨されません。 CGI プロセスを頻繁に作成および削除することで、多大なオーバーヘッドが発生します。 代替手段として、FastCGI、ISAPI アプリケーション スクリプト、ASP または ASP.NET スクリプトを使用することをおすすめします。 いずれの選択肢でも、分離を使用できます。