🥨 💀 👔 ASP.NET最適化-IISを使用するための実用的なヒント 🏠 🤑 🧑

この出版物では、リモートWebサービスを呼び出し、標準の.NETクラスを介してサーバー側のネットワークを積極的に操作する際に、ASP.NETアプリケーションのプールに重要なパラメーターを設定することに焦点を当てます。

はじめに

Windows Server 2008 R2 / IIS 7.5以降を実行している運用Webサーバーを自分でセットアップする必要がありましたか？ IISの使用経験が豊富なシステム管理者にとって、これはたぶん簡単な作業ですが、さまざまな理由で「戦闘」サーバーのセットアップに参加しなければならないWeb開発者にとって、この情報は非常に役立ちます。

それでは、始めましょう。 ASP.NETでのサイトの高速化-企業のお金と管理者の神経を節約します。

背景

1. IIS構成オプション

2. ASP.NETを構成する

3.基本構成を最適化するための推奨事項

オプショナル

おわりに

参照資料

背景

昨年末、ある大規模な組織で、ユーザーの負荷が急激に増加するというWebサーバーのパフォーマンスの問題に直面しました。当時、200,000人以上の顧客がWebアプリケーションに登録されていました。通常モードでは、約1000人のユーザーが同時に作業します。これは、1日あたりの登録ユーザーの総数のユニークビジターの約10〜15％であるため、負荷は比較的低くなります。ただし、システムが実際に動作不能になるピーク負荷があります。

Web管理者は可能なすべてをチェックしましたが、何が問題なのか理解できませんでした。実際、物理レベルでのシステムのすべての主要なパラメーターについてはパフォーマンスが良好であるという事実にもかかわらず、サービスの可用性に障害があり、リクエストの膨大なキューがプールに収集されました。組織は4つのノード（Windows Server 2008 R2 + IIS 7.5 + .NET 4.5）にNLBクラスターを使用します。CPUとメモリを読み込むための予備があり、ネットワークチャネルが大きく、使用するポートの数は十分です。すべてのチェックは、問題がIISの腸とASP.NETプールの構成にあることを示しました。管理者が経験豊富なWeb開発者の助けを傷つけないような生きた例...

1. IIS構成オプション

.NET構成の概要

IIS 7以降、すべてのASP.NET構成設定はXMLファイル（* .config）に保存されます。 IIS 6.0以前で使用されていたメタベースを置き換えました。

IIS 7.x以降の構成ファイル図は次のようになります。

図 1.設定ファイルのスキーム

階層.NET構成の最上部にあるのはmachine.configファイルです 。特定のマシンのグローバルパラメータを定義します。このファイルは、構成ファイルのサポートされているセクションを定義し、ASP.NETワークフローを構成し、さまざまなモジュールプロバイダーを登録します。初期化プロセスを最適化するために、 machine.configファイルは大幅に簡素化され、次のディレクトリに配置されています。

%systemroot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\

machine.config.commentsファイルは次のとおりです。これにより、デフォルトで使用されているパラメーターを確認できます。このデータを使用して、オーバーライドされた値を持つパラメーターをmachine.configに追加できます。

ASP.NET構成階層のルートは、 machine.configと同じディレクトリにあるweb.configファイルです 。このファイルには、すべてのASP.NETアプリケーションに使用されるパラメーターが含まれています。

ApplicationHost.config-ルートIIS構成ファイルには、すべてのサイト、アプリケーション、仮想ディレクトリ、アプリケーションプールの説明、およびWebサーバー設定のグローバルなデフォルト設定が含まれます。 OSバージョンに応じて、次のフォルダーにあります。

32ビットの場合-％WINDIR％\ System32 \ inetsrv \ config \
64ビットの場合-％WINDIR％\ SysWOW64 \ inetsrv \ config \

各ローカルweb.configファイルは、それが置かれているディレクトリとすべての子ディレクトリの構成設定を適用します。サブディレクトリの設定は、独自の「configs」で上書きできます。

IISの構成を開始する前に、ASP.NETパフォーマンスカウンターに注意を払い、現在および最大のシステム負荷を評価し、利用可能なインジケーターを修正します。「HTTPエラー503.2-サービスが利用できません」というエラーのログを確認します。リクエストの一部がキューでブロックされているかどうかを確認してください。

システムのパフォーマンスが顧客のニーズを満たしている場合、ほとんどのASP.NETアプリケーション用に設計されているため、デフォルト設定のままにしておくことをお勧めします。

IISを構成する場合、アプリケーションの可用性とそのパフォーマンスに影響する2つの主要なパラメーターがあります。

1.パラメーターappConcurrentRequestLimitは、アプリケーション内の同時リクエストの最大数です。同時リクエストの数を増やすと、IISはリクエストを処理するために利用可能なWebサーバーリソースを拡張します。デフォルト値は5000です。

appConcurrentRequestLimitパラメーターを変更する最も簡単な方法は、コマンドラインからappcmd.exeユーティリティを使用することです。これは、 ApplicationHost.configファイルを使用してすべてのIISサイトに対してグローバルに実行することも、単一のサイト（アプリケーション）に対して実行することもできます。

 cd %windir%\system32\inetsrv appcmd.exe set config /section:system.webserver/serverRuntime /appConcurrentRequestLimit:20000

コマンドを実行し、IISのルートディレクトリの「構成エディター」セクションを開き、set appConcurrentRequestLimitパラメーターの新しい値を確認します。ここで、この値を手動で変更できます。

図 2. appConcurrentRequestLimitの設定

このパラメーターを設定するために、最も一般的に使用される式は次のとおりです。

< usersCount * 1.5 >、 usersCountは同時ユーザーの数です。

2. QueueLengthパラメーターは、Http.sysドライバーがアプリケーションプールキューに入れる要求の最大数です。キューがいっぱいになると、新しいリクエストに「503.2-Service Unavailable」というエラーが表示されます。デフォルト値は5000です。

このパラメーターは、いくつかの方法で構成できます。

machine.configセクションprocessModel / requestQueueLimitを介したサーバーレベルでの.NETのグローバル
ApplicationHost.configを介してIISレベルで：system.web / httpRuntime-> appRequestQueueLimit;
特定のプールのqueueLengthパラメーターの値を設定します。

例として、コマンドラインを使用して「DefaultAppPool」プールのこのパラメーターを変更します。

 appcmd.exe set apppool "DefaultAppPool" /queueLength:20000

コマンドを実行し、IISで[アプリケーションプール]セクションを開き、リストで[DefaultAppPool]プールを選択し、[詳細設定]メニューに移動して確認します。

図 3. queueLengthパラメーターの設定

注：「IIS-> Worker Processes」を介して実行中のプールの現在のリクエストを表示する

IISマネージャーで、ツリー内のサーバーノードを選択し、[ワーカープロセス]アイコンをクリックします。

図 4. IISマネージャーのワーカープロセスメニュー

表示されるリストで、現在実行中のすべてのプールのダウンロードを確認できます。

図 5.ワーカープロセスを介して作業プールを表示する

[現在のリクエストを表示]をクリックすると、処理されたページアドレスとその他の便利なパラメーターのリストを含むテーブルが表示されます。リストを更新するには、画面でF5を押します。したがって、「ハング」クエリを見つけることができます。

図 6.プール内の現在のリクエストのリスト

もちろん、パフォーマンスインジケーターを表示するには、パフォーマンスモニターカウンターを使用することをお勧めしますが、リクエストモニターのように、現在のリクエストのURLは表示されません。

2. ASP.NETを構成する

ASP.NETは、リクエストの実行に使用されるワーカースレッドと呼び出し終了ポートスレッドの数を制限します。サーバー側のWebアプリケーションが、System.NET名前空間の標準クラスである外部Webサービス呼び出しを広範囲に使用してネットワーク経由で要求を整理すると、パフォーマンスの低下とデッドロックの競合が発生する可能性があります。最初は、リクエストの一部が単純に「ハング」することがあり、実行時間が大幅に増加します。最悪の場合、クラシックプール構成モード（クラシックパイプライン）を使用すると、一般的にプールの再起動（リサイクル）につながる可能性があります。 統合モードで実行されているプールのASP.NETデッドロック検出は失敗します（IIS 7以降のデフォルト）。

統合モードでアプリケーションプールを使用すると、クラシックモードでの作業よりもいくつかの利点があります。統合モードでアプリケーションプールを実行することをお勧めします。

次の図は、ASP.NETでの要求の処理方法と最も重要なパラメーターを明確に示しています。

図 7. ASP.NETのリクエスト処理プロセス

Webアプリケーションのパフォーマンスを最適化するために、プール設定の自動構成のデフォルトモードが有効になっています。この場合、 machine.configファイルの < processModel >セクションのautoConfig プロパティは「 true 」であり、他の主要なパラメーターはまったく設定されていません。

MSDNとmachine.config.commentsファイルを徹底的に「調べ」て、プールの基本構成の説明を見つけました。 ASP.NETがサービスおよびネットワークと連携する方法に影響する7つの主要なパラメーターがあります。

maxConnection
maxWorkerThreads / minWorkerThreads
maxIoThreads / minIoThreads
minFreeThreads
minLocalRequestFreeThreads

maxconnectionパラメーターは、1つのIPアドレスからの同時要求の最大数を決定します。プールの自動構成がデフォルトで有効になっている場合、このパラメーターは式によって決定されます。

maxConnection = 12 * cpuNum 、ここでcpuNumはプロセッサコアの数

したがって、4コアプロセッサを搭載したサーバーでは、最終IPアドレスへの同時接続の最大数は48 = 12 * 4（デフォルト）です。

この制限を回避する最も簡単な方法は、ASP.NETアプリケーションのコードでglobal.asaxファイルのApplication_Startメソッドで次を直接指定することです。

 // maximum number of concurrent connections allowed by a ServicePoint object System.Net.ServicePointManager.DefaultConnectionLimit = Int16.MaxValue;

アプリケーションドメインレベル（web.config）またはWebサーバー（applicationHost.config）の構成ファイルを使用して、 maxconnectionをより柔軟に構成することをお勧めします。 < system.net >セクションには、.NET Frameworkがネットワークに接続する方法を決定するパラメーターが含まれています。

 <system.net> <connectionManagement> <add address="*" maxconnection="5000" /> <add address = "http://www.habrahabr.ru" maxconnection = "9999" /> <add address = "http://65.53.32.230:88" maxconnection = "240" /> </connectionManagement> </system.net>

重要： maxconnectionパラメータアドレスのレイアウトは次のようになります。

 http(s)://<IP-   >:<>

maxconnectionを増やすと、リモートサービスに対してより多くの同時呼び出しを行うことができます。 この属性は、ローカルWebサービスの呼び出しには影響しません！ サービスへの同時接続数の制限をバイパスするだけでは不十分であることを理解する必要があります。同時呼び出しの数が増加すると、リモートの作成とコールバックの処理に使用されるCLRフローの使用が増加するためです。

ASP.NETは、 maxWorkerThreadsパラメーターを使用して、 w3wp.exeワークフロー （IIS 7以降）のスレッド制限を設定します。 ASP.NETはIISに組み込まれているため、ASP.NETプロセスはワーカースレッドでリクエストを生成します。 CLR ThreadPoolのスレッド数が不十分なため、要求はキューに入れられてハングします。

< processModel >セクションで指定された属性：

1.パラメーターmaxWorkerThreads -CLR環境のスレッドプール内の各プロセッサーのワーカースレッドの最大数を示します。デフォルト値は20です。最大値は100です。

2. maxIoThreadsパラメーター-CLRスレッドプール内の各プロセッサーの入力/出力スレッドの最大数を示します。デフォルト値は20です。最大値は100です。

3.パラメータminWorkerThreads-リモートリクエストを処理するためにすぐに提供できる各プロセッサのワークスレッドの最小数を示します。デフォルト値は1です。

4. minIoThreadsパラメーター-コールバック処理にすぐに提供できる各プロセッサーの入力/出力スレッドの最小数を示します。デフォルト値は1です。

パラメータminWorkerThreads / minIoThreadsを使用すると、 非アクティブの場合にスレッドプールが最適なスレッドレベルに到達するのに十分な時間がない場合に、突然増加する同時接続数にすばやく対処できます。

< httpRuntime >セクションで定義されている属性：

1.パラメータminFreeThreads-ワークフローへの着信要求の処理に加えて、作業に使用できるスレッドの数を決定します。このパラメーターは、プール内のスレッドの合計数がこの制限を下回った場合に、ASP.NETプロセスがプールのスレッドを使用して新しいHTTP要求を処理するのを防ぎます。デフォルト値は8です。

2.パラメータminLocalRequestFreeThreads-ASP.NETが新しいローカルリクエストに使用できる空きスレッドの最小数を決定します。デフォルト値は4です。

パラメーターmaxWorkerThreads 、 minWorkerThreads 、 maxIoThreads 、 minIoThreadsには暗黙的にプロセッサーの数が掛けられ、パラメーターminFreeThreadsおよびminLocalRequestFreeThreadsは掛けられないことに注意してください。

ASP.NETは、次の同時リクエスト数を超えて実行しません。

（ maxWorkerThreads * CPU番号 ） -minFreeThreads

注：アプリケーションプール全体、つまり、プールを提供する各w3wp.exeワーカープロセスに対して、1つのCLR ThreadPoolスレッドプールがあります。 1つのプールで構成されたすべてのアプリケーションドメイン（サイト）に対して、共通のスレッドセットが使用されます。したがって、リソースを必要とするアプリケーションの場合は、個別のプールを使用することをお勧めします。

3.基本構成を最適化するための推奨事項

まず、Webサーバー上のプロセッサの数を正確に判断する必要があります。または、TaskManager->タブ「Performance」を見ることができます。プロセッサがHyperThreadingTechnology （HTT）モードをサポートしている場合、コアの半分は物理（コア）ではなく論理（論理プロセッサ）です。たとえば、HTTモードが有効になっている場合、4つの物理コアを持つプロセッサーは8つの論理コアとして機能します。

図 8. TaskManagerのプロセッサロードウィンドウ

コマンドラインで次のコマンドを使用して試すこともできます。

 WMIC CPU Get DeviceID,NumberOfCores,NumberOfLogicalProcessors

または

 echo %NUMBER_OF_PROCESSORS%

たとえば、4つのプロセッサとautoConfig = " true "プロパティを持つサーバーでは、ASP.NETには次のデフォルト設定があります。

maxConnection-48; maxWorkerThreads-80; maxIoThreads-80、minFreeThreads-8、minLocalRequestFreeThreads-4。

バックエンド部分のWebページが各リクエストに対して複数のネットワーク呼び出しを行う場合、MSDNは次の構成設定を使用することをお勧めします。

maxWorkerThreads = 100 | minWorkerThreads = maxWorkerThreads / 2 = 50
maxIoThreads = 100
maxConnection = 12 * N
minFreeThreads = 88 * N
minLocalRequestFreeThreads = 76 * N、ここでNはプロセッサの数です。

このセクションでは、ガイドラインのみを提供し、ルールは提供しません。さらに、このデータの公開日はかなり古いです。「戦闘」システムでは、わずかに異なる構成パラメーターを使用します。これらの式は、最適化を開始するための良い出発点であり、パラメーターの相互依存性をよく示しています。たとえば、 maxConnectionパラメーターの値を数回増やすと、残りのパラメーターの基本値を簡単に「推定」できます。

< processModel >セクションへの変更は、 processModelセクションの追加時にallowDefinition = " MachineOnly "属性が設定さ れているため、 machine.configファイルでのみ許可されます。

C：\ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Config \ Machine.config ：

 <section name="processModel" type="System.Web.Configuration.ProcessModelSection, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" allowDefinition="MachineOnly" allowLocation="false" />

web.configを使用して各アプリケーションのprocessModelセクションの値を個別に設定できるようにするには、プロパティallowDefinition = " Everywhere "を設定する必要があります。

Webサーバーから構成設定を取得します

 <system.web> <processModel autoConfig="False" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" minIoThreads="8" /> <httpRuntime minFreeThreads="640" minLocalRequestFreeThreads="96"> </system.web> <system.net> <connectionManagement> <add address = "http://__1" maxconnection = "5000" /> <add address = "http://__2" maxconnection = "5000" /> </connectionManagement> </system.net>

重要：変更を行った後、アプリケーションプールを更新する必要があります。

十分なCPUリソースがある場合、必要な場合にのみこれらのパラメーターを増やす必要があることに注意してください。

Webサーバーのパフォーマンスを分析するには、パフォーマンスモニターでASP.NETカウンターを設定することをお勧めします。

ASP.NETアプリケーション\要求/秒
Webサービス\ ISAPI拡張リクエスト/秒
ASP.NET \現在のリクエスト
ASP.NET \ Requests Queued
ASP.NET \拒否されたリクエスト
ASP.NETアプリケーション\要求の実行
ASP.NETアプリケーション\要求がタイムアウトしました
ASP.NET \要求実行時間

IISアプリケーションプールを提供するw3wp.exeプロセスの詳細な分析については、 Windows Software Development KitからWinDbgデバッガーを試すことができます。

カウンタを確認した後、システムの構成を調整する必要がある場合があります。

オプショナル

IISの理解を深めるために、この便利な記事「IISアーキテクチャの基礎、またはASP.NETのクエリ提供」で、ユーザーのブラウザーからASP.NETアプリケーションの最終プールへのリクエストを処理するプロセスをよく理解することをお勧めします。

IIS8を使用する場合、「本格的なCPU負荷調整（CPU調整）」に注意を払う必要はありません。

おわりに

サーバー側で頻繁にネットワーク要求を行わないサイトでは、標準のプール設定で十分です（processModel / autoConfig =“ true”）。同時に、IISはコアあたり20のワーカースレッドと12のリモート接続の制限を設定します。これらの値を超えると、リクエストがキューイングを開始し、Webアプリケーションのパフォーマンスが低下します。

サイトが正常に機能し、システムの推定負荷を推定できる場合は、何も変更しないでください。さまざまなサービスへのリクエストを処理する際に「フリーズ」を開始した場合、すぐにすべてを責めるべきではありません！ ASP.NETの基本構成を変更することをお勧めします。アプリケーションプールの基本設定を変更すると、確かにプロセッサの負荷が増加することに注意してください。すべてのシステムパラメータの最適なバランスは、機器の安定した生産的な操作の鍵です。ことわざにあるように、「事前に警告された」とは武装したことを意味します。

Windows Serverプラットフォームでの運用Webサーバーの運用の設定と最適化に関する経験を共有してください。

ASP.NET最適化-IISを使用するための実用的なヒント