IIS 10.0 のチューニング

インターネット インフォメーション サービス (IIS) 10.0 は、Windows Server 2022 に含まれています。 IIS 8.5 および IIS 7.0 と同様のプロセス モデルを使用します。 カーネル モード Web ドライバー (http.sys) は、HTTP 要求を受信してルーティングし、応答キャッシュから要求を満たします。 ワーカー プロセスは URL サブスペースに登録され、http.sys は要求を適切なプロセス (またはアプリケーション プールの一連のプロセス) にルーティングします。

HTTP.sys は、接続管理と要求処理を担当します。 要求は、HTTP.sys キャッシュから処理することも、ワーカー プロセスに渡してさらに処理することもできます。 複数のワーカープロセスを構成できるため、低コストで分離を実現できます。 要求処理のしくみの詳細については、次の図を参照してください。

HTTP.sys には応答キャッシュが含まれています。 要求が応答キャッシュのエントリと一致すると、HTTP.sys はカーネル モードから直接キャッシュ応答を送信します。 ASP.NET などの一部の Web アプリケーション プラットフォームには、任意の動的コンテンツをカーネル モード キャッシュにキャッシュできるメカニズムが用意されています。 IIS 10.0 の静的ファイル ハンドラは、頻繁に要求されるファイルを http.sys.

Web サーバーにはカーネル モード コンポーネントとユーザー モード コンポーネントがあるため、最適なパフォーマンスを得るには両方のコンポーネントを調整する必要があります。 したがって、特定のワークロードに対する IIS 10.0 のチューニングには、次の構成が含まれます。

• HTTP.sys と関連するカーネル モード キャッシュ

• ワーカー プロセスとユーザー モード IIS (アプリケーション プール構成を含む)

• パフォーマンスに影響を与える特定のチューニングパラメータ

次のセクションでは、IIS 10.0 のカーネル モードとユーザー モードの側面を構成する方法について説明します。

カーネル モードの設定

パフォーマンス関連の HTTP.sys 設定は、キャッシュ管理と接続および要求管理の 2 つの大きなカテゴリに分類されます。 すべてのレジストリ設定は、次のレジストリ エントリに格納されます。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters

手記 HTTP サービスがすでに実行中の場合は、変更を有効にするために HTTP サービスを再起動する必要があります。

キャッシュ管理設定

HTTP.sys が提供する利点の 1 つは、カーネル モード キャッシュです。 応答がカーネル モード キャッシュにある場合は、カーネル モードから HTTP 要求を完全に満たすことができるため、要求の処理にかかる CPU コストが大幅に削減されます。 ただし、IIS 10.0 のカーネル モード キャッシュは物理メモリに基づいており、エントリのコストはそれが占めるメモリです。

キャッシュ内のエントリは、使用する場合にのみ役立ちます。 ただし、エントリは、エントリが使用されているかどうかに関係なく、常に物理メモリを消費します。 キャッシュ内の項目の有用性 (キャッシュから項目を提供できることによる節約) と、エントリの有効期間中のコスト (占有される物理メモリ) は、使用可能なリソース (CPU と物理メモリ) とワークロード要件を考慮して評価する必要があります。 HTTP.sys は、アクティブにアクセスされる有用な項目のみをキャッシュに保持しようとしますが、特定のワークロードに対して HTTP.sys キャッシュを調整することで、Web サーバーのパフォーマンスを向上させることができます。

HTTP.sys カーネル モード キャッシュの便利な設定を次に示します。

• UriEnableCache(英語) デフォルト値: 1

  0 以外の値を指定すると、カーネル モードの応答とフラグメント キャッシュが有効になります。 ほとんどのワークロードでは、キャッシュは有効なままにしておく必要があります。 応答が非常に低く、フラグメント キャッシュが発生すると予想される場合は、キャッシュを無効にすることを検討してください。

• UriMaxCacheMegabyteCount デフォルト値: 0

  カーネル モード キャッシュで使用できる最大メモリを指定する 0 以外の値。 デフォルト値の 0 を使用すると、システムはキャッシュで使用可能なメモリ量を自動的に調整できます。

  手記 サイズを指定すると、最大サイズのみが設定され、システムはキャッシュを最大設定サイズまで拡張できない場合があります。

  Â

• UriMaxUriバイト デフォルト値: 262144バイト (256 KB)

  カーネル モード キャッシュ内のエントリの最大サイズ。 これより大きい応答またはフラグメントはキャッシュされません。 十分なメモリがある場合は、制限を増やすことを検討してください。 メモリが限られており、大きなエントリが小さなエントリをクラウディングしている場合は、制限を下げると役立つ場合があります。

• UriScavengerピリオド デフォルト値: 120 秒

  HTTP.sys キャッシュはスカベンジャーによって定期的にスキャンされ、スカベンジャースキャンの間にアクセスされないエントリは削除されます。 スカベンジャー期間を高い値に設定すると、スカベンジャースキャンの数が減ります。 ただし、アクセス頻度の低い古いエントリがキャッシュに残る可能性があるため、キャッシュメモリの使用量が増加する可能性があります。 期間の設定が小さすぎると、スカベンジャー スキャンの頻度が高くなり、フラッシュが多すぎてキャッシュ チャーンが発生する可能性があります。

要求と接続の管理設定

Windows Server 2022 では、HTTP.sys によって接続が自動的に管理されます。 次のレジストリ設定は使用されなくなりました。

• マックスコネクション

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\MaxConnections
  

• アイドル接続ハイマーク

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsHighMark
  

• アイドル接続ローマーク

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsLowMark
  

• IdleListTrimmerPeriod (アイドル リスト トリマー期間)

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleListTrimmerPeriod
  

• RequestBufferLookasideDepth (リクエストバッファルックアサイドデプス)

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\RequestBufferLookasideDepth
  

• 内部リクエストルックアサイドデプス

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\InternalRequestLookasideDepth
  

ユーザーモードの設定

このセクションの設定は、IIS(TM) 10.0 ワーカー プロセスの動作に影響します。 これらの設定のほとんどは、次の XML 設定ファイルにあります。

%SystemRoot%\system32\inetsrv\config\applicationHost.config

Appcmd.exe、IIS 10.0 管理コンソール、WebAdministration、または IISAdministration PowerShell コマンドレットを使用して変更します。 ほとんどの設定は自動的に検出され、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 と numaNodeAffinityMode) とは異なります。 理想的な CPU 設定は、IIS がスレッド プール スレッドを分散する方法に影響しますが、ワーカー プロセスの NUMA ノード割り当て設定によって、ワーカー プロセスが開始する NUMA ノードが決まります。

ユーザー モードのキャッシュ動作の設定

このセクションでは、IIS(R) 10.0 でのキャッシュ動作に影響を与える設定について説明します。 ユーザー モード キャッシュは、統合パイプラインによって発生するグローバル キャッシュ イベントをリッスンするモジュールとして実装されます。 ユーザー モード キャッシュを完全に無効にするには、applicationHost.configの system.webServer/globalModules 構成セクションで、インストールされているモジュールの一覧から FileCacheModule (cachfile.dll) モジュールを削除します。

system.webServer/キャッシング

圧縮動作の設定

7.0 以降の IIS では、デフォルトで静的コンテンツが圧縮されます。 また、動的コンテンツの圧縮は、DynamicCompressionModule のインストール時に既定で有効になります。 圧縮により、帯域幅の使用量は減少しますが、CPU の使用量は増加します。 圧縮されたコンテンツは、可能であればカーネル モード キャッシュにキャッシュされます。 8.5 以降、IIS では、静的コンテンツと動的コンテンツの圧縮を個別に制御できます。 静的コンテンツとは、通常、GIF ファイルや HTM ファイルなど、変更されないコンテンツを指します。 動的コンテンツは、通常、サーバー上のスクリプトまたはコード (ASP.NET ページ) によって生成されます。 特定の拡張機能の分類を静的または動的にカスタマイズできます。

圧縮を完全に無効にするには、applicationHost.configの system.webServer/globalModules セクションのモジュールの一覧から StaticCompressionModule と DynamicCompressionModule を削除します。

system.webServer/httpCompression (英語)

system.webServer/url圧縮

デフォルトのドキュメントリストのチューニング

デフォルトのドキュメントモジュールは、ディレクトリのルートに対する HTTP リクエストを処理し、それらを Default.htm や Index.htmなどの特定のファイルに対するリクエストに変換します。 平均して、インターネット上のすべての要求の約 25% が既定のドキュメント パスを経由します。 これは、個々のサイトによって大きく異なります。 HTTP 要求でファイル名が指定されていない場合、デフォルトのドキュメントモジュールは、ファイルシステム内の各名前について、許可されたデフォルトドキュメントのリストを検索します。 これは、特にコンテンツに到達するためにネットワーク ラウンド トリップを行ったり、ディスクに触れたりする必要がある場合に、パフォーマンスに悪影響を与える可能性があります。

このオーバーヘッドを回避するには、デフォルトのドキュメントを選択的に無効にしたり、ドキュメントのリストを縮小または並べ替えたりします。 既定のドキュメントを使用する Web サイトの場合は、リストを既定のドキュメントの種類のみに減らす必要があります。 さらに、最も頻繁にアクセスされるデフォルトのドキュメントファイル名で始まるようにリストを並べ替えます。

特定の URL に対するデフォルトのドキュメントの動作を選択的に設定するには、applicationHost.config の ___location タグ内の設定をカスタマイズするか、web.config ファイルをコンテンツディレクトリに直接挿入します。 これにより、必要な場合にのみデフォルトのドキュメントを有効にし、各URLの正しいファイル名にリストを設定するハイブリッドアプローチが可能になります。

デフォルトのドキュメントを完全に無効にするには、applicationHost.configの system.webServer/globalModules セクションのモジュールの一覧から DefaultDocumentModule を削除します。

system.webServer/defaultDocument

中央バイナリロギング

サーバー セッションの下に多数の URL グループがある場合、個々の URL グループに対して数百の書式設定されたログ ファイルを作成し、ログ データをディスクに書き込むプロセスでは、貴重な CPU とメモリ リソースがすぐに消費され、パフォーマンスとスケーラビリティの問題が生じる可能性があります。 一元化されたバイナリロギングは、ロギングに使用されるシステムリソースの量を最小限に抑えると同時に、それを必要とする組織に詳細なログデータを提供します。 バイナリ形式のログを解析するには、後処理ツールが必要です。

セントラル バイナリ ロギングを有効にするには、centralLogFileMode 属性を CentralBinary に設定し、 enabled 属性を True に設定します。 中央ログファイルの場所をシステムパーティションから専用のログドライブに移動して、システムアクティビティとロギングアクティビティの間の競合を避けることを検討してください。

system.applicationHost/log

system.applicationHost/log/centralBinaryLogFile

アプリケーションとサイトのチューニング

次の設定は、アプリケーション プールとサイトのチューニングに関連しています。

system.applicationHost/applicationPools/applicationPoolDefaults(英語)

system.applicationHost/sites/VirtualDirectoryDefault

IIS 10.0 モジュールの管理

IIS 10.0 は、モジュール構造をサポートするために、ユーザーが拡張可能な複数のモジュールに組み込まれています。 この因数分解には小さなコストがかかります。 モジュールごとに、統合パイプラインは、モジュールに関連するすべてのイベントに対してモジュールを呼び出す必要があります。 これは、モジュールが何らかの作業を行う必要があるかどうかに関係なく発生します。 特定の Web サイトに関連しないすべてのモジュールを削除することで、CPU サイクルとメモリを節約できます。

単純な静的ファイル用に調整された Web サーバーには、UriCacheModule、HttpCacheModule、StaticFileModule、AnonymousAuthenticationModule、HttpLoggingModule の 5 つのモジュールのみが含まれる場合があります。

applicationHost.configからモジュールを削除するには、system.webServer/handlers セクションと system.webServer/modules セクションからモジュールへの参照をすべて削除し、さらに system.webServer/globalModules のモジュール宣言を削除します。

クラシック ASP 設定

従来の ASP 要求の処理の主なコストには、スクリプト エンジンの初期化、要求された ASP スクリプトの ASP テンプレートへのコンパイル、およびスクリプト エンジンでのテンプレートの実行が含まれます。 テンプレートの実行コストは要求された ASP スクリプトの複雑さによって異なりますが、IIS クラシック ASP モジュールでは、スクリプト エンジンをメモリにキャッシュし、テンプレートをメモリとディスクの両方にキャッシュして (メモリ内テンプレート キャッシュがオーバーフローした場合のみ)、CPU バインド シナリオのパフォーマンスを向上させることができます。

次の設定は、従来の ASP テンプレート キャッシュとスクリプト エンジン キャッシュを構成するために使用され、ASP.NET 設定には影響しません。

system.webServer/asp/キャッシュ

system.webServer/asp/limitsの

system.webServer/asp/comPlus (英語)

ASP.NET 同時実行性の設定

ASP.NET 3.5

デフォルトでは、ASP.NET は要求の同時実行性を制限して、サーバー上の定常状態のメモリ消費を削減します。 同時実行性の高いアプリケーションでは、全体的なパフォーマンスを向上させるために一部の設定を調整する必要がある場合があります。 この設定は aspnet.config ファイルで変更できます。

<system.web>
  <applicationPool maxConcurrentRequestsPerCPU="5000"/>
</system.web>

次の設定は、システム上のリソースを完全に使用する場合に便利です。

• maxConcurrentRequestPerCpu デフォルト値: 5000

  この設定は、システム上で同時に実行される ASP.NET リクエストの最大数を制限します。 デフォルト値は、ASP.NET アプリケーションのメモリ消費を減らすために控えめです。 長い同期入出力操作を実行するアプリケーションを実行するシステムでは、この制限を増やすことを検討してください。 そうしないと、デフォルト設定が使用されている場合に高負荷でキュー制限を超えることによるキューイングや要求の失敗により、ユーザーは待ち時間を長く感じる可能性があります。

ASP.NET 4.6

maxConcurrentRequestPerCpu 設定の他に、ASP.NET 4.7 には、非同期操作に大きく依存するアプリケーションのパフォーマンスを向上させる設定も用意されています。 設定は aspnet.config ファイルで変更できます。

<system.web>
  <applicationPool percentCpuLimit="90" percentCpuLimitMinActiveRequestPerCpu="100"/>
</system.web>

• パーセントCpuLimit 既定値: 90 非同期要求には、このようなシナリオに (ハードウェア機能を超える) 大きな負荷がかかると、スケーラビリティの問題が発生します。 この問題は、非同期シナリオでの割り当ての性質によるものです。 このような状況では、非同期操作の開始時に割り当てが行われ、完了時に消費されます。 その時までに、オブジェクトが GC によってジェネレーション 1 または 2 に移動されている可能性が非常に高いです。 これが発生すると、負荷を増やすと、ある時点まで 1 秒あたりの要求数 (rps) の増加が表示されます。 そのポイントを過ぎると、GCに費やされる時間が問題になり始め、rpsが減少し始め、スケーリングに悪影響を及ぼします。 この問題を解決するために、CPU 使用率が percentCpuLimit 設定を超えると、要求は ASP.NET ネイティブ キューに送信されます。
• パーセントCpuLimitMinActiveRequestPerCpu 既定値: 100 CPU スロットリング (percentCpuLimit 設定) は、要求の数ではなく、要求のコストに基づいています。 その結果、CPU を集中的に使用する要求が数個あるだけで、ネイティブ キューにバックアップが作成され、受信要求以外にバックアップを空にする方法がない可能性があります。 この問題を解決するには、percentCpuLimitMinActiveRequestPerCpu を使用して、スロットルが開始される前に最小数のリクエストが処理されていることを確認できます。

労働者のプロセスとリサイクルのオプション

IIS ワーカー プロセスをリサイクルするためのオプションを構成し、サービスやコンピューターの介入やリセットを必要とせずに、深刻な状況やイベントに対する実用的なソリューションを提供できます。 このような状況やイベントには、メモリ リーク、メモリ負荷の増加、応答しない、またはアイドル状態のワーカー プロセスが含まれます。 通常の条件下では、リサイクル オプションは必要なく、リサイクルをオフにするか、リサイクルの頻度が非常に低いようにシステムを構成できます。

特定のアプリケーションに対してプロセス・リサイクルを有効にするには、 recycling/periodicRestart エレメントに属性を追加します。 リサイクル イベントは、メモリ使用量、固定数の要求、固定期間など、いくつかのイベントによってトリガーできます。 ワーカー プロセスがリサイクルされると、キューに入れられた要求と実行中の要求がドレインされ、新しい要求を処理するための新しいプロセスが同時に開始されます。 recycling/periodicRestart 要素はアプリケーションごとであり、次の表の各属性はアプリケーションごとにパーティション分割されます。

system.applicationHost/applicationPools/ApplicationPoolDefaults/recycling/periodicRestart

ワーカー・プロセス間の動的ページアウト・チューニング

Windows Server 2012 R2 以降、IIS では、ワーカー プロセスがしばらくアイドル状態になった後に中断するように構成するオプションが提供されます (IIS 7 以降に存在していた終了のオプションに加えて)。

アイドル ワーカー プロセスのページアウト機能とアイドル ワーカー プロセスの終了機能の両方の主な目的は、サイトがそこに座ってリッスンしているだけでも大量のメモリを消費する可能性があるため、サーバー上のメモリ使用率を節約することです。 サイトで使用されているテクノロジー(静的コンテンツ、ASP.NET、他のフレームワーク)に応じて、使用されるメモリは約10MBから数百MBの範囲になる可能性があり、これは、サーバーが多くのサイトで構成されている場合、サイトの最も効果的な設定を見つけることで、アクティブなサイトと一時停止されたサイトの両方のパフォーマンスを劇的に向上させることができることを意味します。

詳細に入る前に、メモリの制約がない場合は、サイトを一時停止または終了しないように設定するのがおそらく最善であることを覚えておく必要があります。 結局のところ、ワーカープロセスがマシン上で唯一のものである場合、ワーカープロセスを終了することにはほとんど価値がありません。

考慮すべき別の要因は、サイトが大量のメモリを使用している場合、ワーカー プロセスによって使用されるデータをディスクにコンピューターが書き込む必要があるため、中断プロセス自体が負荷になるということです。 ワーカー プロセスが大量のメモリを使用している場合、ワーカー プロセスを中断すると、バックアップの開始を待つコストよりもコストがかかる可能性があります。

ワーカー プロセスの中断機能を最大限に活用するには、各アプリケーション プール内のサイトを確認し、中断するサイト、終了するサイト、無期限にアクティブにするサイトを決定する必要があります。 各アクションと各サイトについて、理想的なタイムアウト期間を把握する必要があります。

理想的には、一時停止または終了のために設定するサイトは、毎日訪問者がいるサイトですが、常にアクティブに保つことを保証するほどではありません。 これらは通常、1日に約20人のユニークビジターがいるサイトです。 サイトのログファイルを使用してトラフィックパターンを分析し、日次平均トラフィックを計算できます。

特定のユーザーがサイトに接続すると、通常、少なくともしばらくはサイト上に滞在し、追加のリクエストを行うため、毎日のリクエストを数えるだけでは実際のトラフィックパターンが正確に反映されない可能性があることに注意してください。 より正確な読み取りを得るために、Microsoft Excelなどのツールを使用して、リクエスト間の平均時間を計算することもできます。 例えば次が挙げられます。

しかし、難しいのは、どのような設定を適用すれば意味をなすのかを考えることです。 私たちの場合、サイトはユーザーから大量のリクエストを受け取り、上の表は4時間の間に合計4つのユニークなセッションが発生したことを示しています。 アプリケーションプールのワーカープロセスの中断のデフォルト設定では、デフォルトのタイムアウトである 20 分後にサイトが終了するため、これらの各ユーザーはサイトのスピンアップサイクルを経験することになります。 これにより、ほとんどの場合、サイトはアイドル状態であるため、サイトを一時停止するとリソースが節約され、ユーザーはほぼ瞬時にサイトにアクセスできるため、ワーカープロセスの一時停止の理想的な候補になります。

これに関する最後の、そして非常に重要な注意点は、この機能にとってディスクのパフォーマンスが重要であるということです。 サスペンドとウェイクアップのプロセスには、ハードドライブへの大量のデータの書き込みと読み取りが含まれるため、これには高速ディスクを使用することを強くお勧めします。 ソリッドステートドライブ(SSD)は理想的であり、これには強く推奨され、Windowsページファイルが保存されていることを確認する必要があります(オペレーティングシステム自体がSSDにインストールされていない場合は、ページファイルをSSDに移動するようにオペレーティングシステムを構成します)。

SSD を使用するかどうかに関係なく、ページアウト データを書き込むときにファイルのサイズを変更せずにページ ファイルのサイズを固定することもお勧めします。 既定では、Windows は必要に応じてサイズを自動的に調整するように構成されているため、オペレーティング システムがページ ファイルにデータを格納する必要がある場合に、ページ ファイルのサイズ変更が発生する可能性があります。 サイズを固定に設定することで、サイズ変更を防ぎ、パフォーマンスを大幅に向上させることができます。

事前に固定されたページファイルサイズを設定するには、一時停止するサイトの数と消費するメモリの量に応じて、理想的なサイズを計算する必要があります。 アクティブなワーカー プロセスの平均が 200 MB で、中断するサーバー上に 500 のサイトがある場合、ページ ファイルはページ ファイルの基本サイズ (この例では基本 + 100 GB) 以上 (200 * 500) MB である必要があります。

Transport Layer Security のチューニング パラメーター

Transport Layer Security (TLS) を使用すると、追加の CPU コストが発生します。 TLSの最も高価な要素は、完全なハンドシェイクを伴うため、セッション確立の確立コストです。 再接続、暗号化、および復号化もコストに追加されます。 TLS のパフォーマンスを向上させるには、次の操作を行います。

• TLS セッションの HTTP キープアライブを有効にします。 これにより、セッションの確立コストが削減されます。

• 必要に応じて、特にキープアライブ以外のトラフィックでセッションを再利用します。

• 暗号化は、サイト全体ではなく、必要なページまたはサイトの一部にのみ選択的に適用します。

インターネット サーバー アプリケーション プログラミング インターフェイス (ISAPI)

ISAPI アプリケーションには、特別なチューニング パラメータは必要ありません。 プライベート ISAPI 拡張機能を作成する場合は、パフォーマンスとリソースの使用を目的として記述されていることを確認してください。

マネージ コード チューニングのガイドライン

IIS 10.0 の統合パイプライン モデルにより、高度な柔軟性と拡張性が実現します。 ネイティブ コードまたはマネージ コードで実装されたカスタム モジュールは、パイプラインに挿入したり、既存のモジュールを置き換えたりすることができます。 この拡張モデルでは便利で簡単ですが、グローバル イベントにフックする新しいマネージ モジュールを挿入する前は注意が必要です。 グローバル マネージ モジュールを追加すると、静的ファイル要求を含むすべての要求がマネージ コードに触れる必要があります。 カスタムモジュールは、ガベージコレクションなどのイベントの影響を受けやすくなります。 さらに、カスタム モジュールでは、ネイティブ コードとマネージ コードの間でデータをマーシャリングするため、CPU コストが大幅に増加します。 可能であれば、マネージド モジュールの preCondition を managedHandler に設定する必要があります。

コールド スタートアップのパフォーマンスを向上させるには、ASP.NET Web サイトをプリコンパイルするか、IIS アプリケーション初期化機能を利用してアプリケーションをウォームアップしてください。

セッション状態が不要な場合は、ページごとにセッション状態をオフにしてください。

I/O バインド操作が多数ある場合は、関連する API の非同期バージョンを使用してみてください。これにより、スケーラビリティが大幅に向上します。

また、出力キャッシュを適切に使用すると、Webサイトのパフォーマンスも向上します。

ASP.NET スクリプトを含む複数のホストを分離モード (サイトごとに 1 つのアプリケーション プール) で実行する場合は、メモリ使用量を監視します。 同時に実行されるアプリケーション プールの予想される数に対して、サーバーに十分な RAM があることを確認します。 複数の分離されたプロセスではなく、複数のアプリケーション ドメインを使用することを検討してください。

IIS のパフォーマンスに影響を与えるその他の問題

次の問題が IIS のパフォーマンスに影響を与える可能性があります。

• キャッシュに対応していないフィルターのインストール

  HTTP キャッシュに対応していないフィルタをインストールすると、IIS はキャッシュを完全に無効にし、パフォーマンスが低下します。 IIS(TM) 6.0 より前に記述された ISAPI フィルタは、この動作を引き起こす可能性があります。

• Common Gateway Interface (CGI) 要求

  パフォーマンス上の理由から、IIS で CGI アプリケーションを使用して要求を処理することはお勧めしません。 CGIプロセスを頻繁に作成および削除すると、かなりのオーバーヘッドが伴います。 より優れた代替手段には、FastCGI、ISAPI アプリケーション スクリプト、ASP または ASP.NET スクリプトの使用が含まれます。 分離は、これらの各オプションで使用できます。

その他の参照情報

• Web サーバーのパフォーマンスチューニング
• HTTP 1.1/2 チューニング