次の方法で共有

パフォーマンス監視の ASP.NET と管理者に警告するタイミング

  • [アーティクル]

 

Thomas Marquardt
Microsoft Corporation

更新日: 2003 年 7 月

適用対象:
   Microsoft® ASP.NET

概要： Microsoft ASP.NET アプリケーションのストレスとパフォーマンスの問題の診断に最も役立つパフォーマンス カウンター、管理者に問題を通知するために設定する必要があるしきい値、および ASP.NET アプリケーションの正常性を監視するために使用できるその他のリソースについて説明します。 (17ページ印刷)

この記事のソース コードをダウンロードします。

Contents

パフォーマンス カウンターの監視
イベント ログの監視
W3C ログと HTTPERR ログの監視
ASP.NET の監視に使用されるその他のリソース
パフォーマンス カウンターについて
   .NET CLR 例外カウンター
   .NET CLR 読み込みカウンター
   .NET CLR メモリ カウンター
   ASP.NET カウンター
   ASP.NET アプリケーション カウンター
   プロセス カウンター
   プロセッサ カウンター
   メモリ カウンター
   システム カウンター
   Web サービス カウンター
まとめ

パフォーマンス カウンターの監視

アプリケーションの監視に使用できるパフォーマンス カウンターは多数あります。 パフォーマンス ログに含めるものを選択するのは難しい場合があり、それらを解釈する方法を学ぶことは芸術です。 この記事は、これらの両方のタスクをより快適に感じるのに役立ちます。

Microsoft ASP.NET アプリケーションでは、少なくとも次の®パフォーマンス カウンターを監視する必要があります。

  • Processor(_Total)\% プロセッサ時間
  • Process(aspnet_wp)\% プロセッサ時間
  • Process(aspnet_wp)\Private Bytes
  • Process(aspnet_wp)\Virtual Bytes
  • Process(aspnet_wp)\Handle Count
  • Microsoft® .NET CLR Exceptions\# Exceps thrown /sec
  • ASP.NET\アプリケーションの再起動
  • ASP.NET\Requests Rejected
  • ASP.NET\Worker プロセスの再起動 (IIS 6.0 には適用されません)
  • メモリ \ 使用可能なメモリ (MB)
  • Web サービス\現在の接続
  • Web サービス\ISAPI 拡張機能要求/秒

パフォーマンスの監視に役立つパフォーマンス カウンターの一覧を次に示します。 特に簡単に再現できない問題が発生した場合は、十分ではないよりも多くのパフォーマンス データを使用することをお勧めします。 一覧には、通常は必要ないパフォーマンス カウンターがいくつか省略されています。 たとえば、セッションの状態とトランザクションのパフォーマンス カウンターは、機能が使用されている場合にのみ必要です。

アプリケーションのデバッグとテストの経験に基づいて、いくつかのしきい値 ASP.NET 推奨されます。 この記事では、"しきい値" を検索してすぐにアクセスできます。 管理者は、エクスペリエンスに基づいて、これらのしきい値を超えたときにアラートを生成するかどうかを決定する必要があります。 ほとんどの場合、アラートは適切です。特に、しきい値が長期間にわたって超えている場合です。

イベント ログの監視

ASP.NET および Microsoft® インターネット インフォメーション サーバー (IIS) からのメッセージのイベント ログを監視することが重要です。 ASP.NET は、たとえば、aspnet_wpワーカー プロセスが終了するたびに、アプリケーション ログにメッセージを書き込みます。 IIS 6.0 は、たとえば w3wp ワーカー プロセスが異常またはクラッシュを報告するたびに、アプリケーションログとシステムログの両方にメッセージを書き込みます。 アプリケーション ログを読み取り、ASP.NET と IIS からメッセージを除外し、必要に応じてアラートを発生させる (電子メールまたはポケットベルにダイヤルする) .NET アプリケーションを作成するのは非常に簡単です。

W3C ログと HTTPERR ログの監視

まず、インターネット インフォメーション サービス (IIS) マネージャーを使用して、IIS 5.0 と IIS 6.0 の W3C ログ記録を有効にします。 このログは、URI、状態コードなど、要求に関するさまざまなデータを含むように構成できます。 ログで 404 Not Found などのエラー コードをスキャンし、必要に応じてリンクを修正するアクションを実行します。 IIS 6.0 では、サブステータス コードがログに含まれており、デバッグに役立ちます。 IIS では、サブステータス コードを使用して特定の問題をインデントします。 たとえば、404.2 は、要求を処理している ISAPI 拡張機能がロックダウンされていることを示します。 状態コードとサブステータス コードの一覧については、「 カスタム エラー メッセージについて 」トピックを参照してください。

IIS 6.0 の新機能、形式が正しくない要求、またはアプリケーション プールで処理できない要求は、HTTP 要求を処理するためのカーネル モード ドライバーである HTTP.SYS によって HTTPERR ログに記録されます。 各エントリには、URL とエラーの簡単な説明が含まれています。

HTTPERR ログで拒否された要求を確認します。 要求は、カーネル要求キューを超えたとき、およびアプリケーションが Rapid Fail Protection 機能によってオフラインになったときに、HTTP.SYSによって拒否されます。 最初の問題が発生すると、URL は QueueFull というメッセージでログに記録され、2 つ目の問題が発生すると、メッセージは AppOffline になります。 既定では、カーネル要求キューは 1,000 に設定され、IIS マネージャーの [アプリケーション プールのプロパティ] ページで構成できます。 この値をビジー サイトの場合は 5,000 に増やすことをお勧めします。これは、サイトの負荷が非常に高いときにアプリケーション プールがクラッシュした場合にカーネル要求キューが 1,000 を簡単に超える可能性があるためです。

ワーカー プロセスのクラッシュまたはハングにより失われた要求がないか HTTPERR ログを確認します。 この場合、URL は、フライト中の要求ごとにメッセージ Connection_Abandoned_By_AppPoolと共にログに記録されます。 処理中の要求は、処理のためにワーカー プロセスに送信されたが、クラッシュまたはハングする前に完了しなかった要求です。

HTTPERR ログの詳細については、Microsoft サポート技術情報の記事 820729 : INFO: HTTP API でのエラー ログ記録に関するページを参照してください。

ASP.NET の監視に使用されるその他のリソース

パフォーマンス カウンターとイベント ログは、発生したすべてのエラーをキャッチするわけではないため、ASP.NET の監視には完全には十分ではありません。 1 つ以上のページに対して HTTP 要求を送信し、特定の応答を期待する単純なアプリケーションを作成することをお勧めします。 このツールでは、ページがタイムリーに提供されるように、最後のバイト (TTLB) までの時間を監視する必要があります。 また、この情報は問題を分析するために必要であるため、発生したエラーも記録する必要があります。

IIS 6.0 リソース キットには、ログ ファイル (W3C ログ、HTTPERR ログ、イベント ログ) を解析し、結果をファイルまたはデータベースに格納するためのツールである Log Parser 2.1 が含まれています。 リソース キットは、Microsoft Windows XP および Microsoft®® Windows® Server™ 2003 にインストールできます。

また、パフォーマンス データを収集し、イベント ログをフィルター処理し、キー データを Microsoft® SQL Server データベースに記録するアプリケーションを作成することもできます。 System.Diagnostics 名前空間を使用してこれを行うのは驚くほど簡単です。 System.Diagnostics.Process クラスを使用してワーカー プロセスの再起動を監視することもできます。

作業を開始するには、この記事の上部にあるリンクを使用して、いくつかの便利なツールのサンプル コードをダウンロードします。

  1. snap.exeのソース コード。プロセスのパフォーマンス データをログに記録するためのコマンド ライン ツールです。 Snap.cs ファイルには簡単な説明が含まれており、ツールをコンパイルする方法について説明します。
  2. HTTP 要求の最後のバイト (TTLB) までの時間を記録する単純なクライアントである、HttpClient.exeのソース コード。 HttpClient.cs ファイルには簡単な説明が含まれており、ツールをコンパイルする方法について説明します。
  3. qqq.exeのソース コード。ASP.NET アプリケーションをストレス テストするためのコマンド ライン ツールです。 Microsoft® Application Center Test (ACT) などのストレス クライアントと組み合わせて使用すると、このツールはデバッガーをワーカー プロセスにアタッチし、特定のパフォーマンス カウンターを監視します。 パフォーマンスが低下したときにデバッガーに中断するように調整できます。 ファイル qqq.cs には breif の説明が含まれており、ツールをコンパイルする方法について説明します。
  4. pminfo.aspx ページでは 、System.Web.ProcessModelInfo クラスを使用して、aspnet_wpのプロセス再起動に関する情報を表示します。 履歴は、w3svc サービスが停止するまで保持されます。
  5. ErrorHandler.dllのソース コード。 これは、HTTP パイプラインに追加して、未処理の例外をイベント ログに記録できる IHttpModule です。 エラーをSQL Server データベースにログに記録することをお勧めしますが、この例では簡単にするためにイベント ログを使用します。

もう 1 つの簡単な手順は 、Application_Errorの実装です。 global.asax に次のテキストを追加し、処理されていないほとんどのエラーのログをアプリケーション ログにすぐに記録できます。

<%@ import namespace="System.Diagnostics" %>
<%@ import namespace="System.Text" %>

const string sourceName      = ".NET Runtime";
const string serverName      = ".";
const string logName         = "Application";
const string uriFormat       = "\r\n\r\nURI: {0}\r\n\r\n";
const string exceptionFormat = "{0}: \"{1}\"\r\n{2}\r\n\r\n";

void Application_Error(Object sender, EventArgs ea) {
    StringBuilder message = new StringBuilder();
    
    if (Request != null) {
        message.AppendFormat(uriFormat, Request.Path);
    }
  
    if (Server != null) {
        Exception e;
        for (e = Server.GetLastError(); e != null; e = e.InnerException) {
            message.AppendFormat(exceptionFormat, 
                                 e.GetType().Name, 
                                 e.Message,
                                 e.StackTrace);
        }
    }

    if (!EventLog.SourceExists(sourceName)) {
        EventLog.CreateEventSource(sourceName, logName);
    }

    EventLog Log = new EventLog(logName, serverName, sourceName);
    Log.WriteEntry(message.ToString(), EventLogEntryType.Error);

    //Server.ClearError(); // uncomment this to cancel the error
}

Application_Error は、ページ内のパーサー、コンパイル、および実行時エラーをキャッチします。 構成の問題をキャッチすることも、要求の処理中に inetinfo 内で発生したエラー aspnet_isapiキャッチすることもありません。 また、偽装を使用する場合、偽装されたトークンには、このイベント ソースに書き込むアクセス許可が必要です。 SQL Server データベースにエラーをログに記録することで、偽装に関する問題を回避できます。

最後に、Microsoft® Debugging Tools for Windows は、運用 Web サーバーでの問題のデバッグに非常に役立ちます。 これらのツールは から https://www.microsoft.com/whdc/ddk/debugging/installx86.mspxダウンロードできます。 sos.dllという名前のデバッガー拡張機能があり、デバッガー windbg.exeに読み込んだり、マネージド コードをデバッグcdb.exeしたりすることができます。 ガベージ コレクション (GC) ヒープの内容のダンプ、マネージド スタック トレースの表示、マネージド ロックの競合の調査、スレッド プールの統計情報の表示などを行うことができます。 これは、「.NET Framework アプリケーションの運用デバッグ」で説明されているデバッグ ツールセットの一部としてダウンロードできます。

パフォーマンス カウンターについて

重要なパフォーマンス カウンターとその使用方法の簡単な説明を次に示します。

.NET CLR 例外カウンター

_Global_ カウンター インスタンスは、すべてのマネージド プロセスによって更新されるため、このカウンターでは使用しないでください。 代わりに、aspnet_wp インスタンスを使用します。

  • #Exceps/ sec がスローされます。1 秒あたりにスローされるマネージド例外の合計数。 この数が増えると、パフォーマンスが低下します。 例外は、通常の処理の一部としてスローしないでください。 ただし、 Response.Redirect、 Server.Transfer、 Response.End はすべて ThreadAbortException を複数回スローし、これらのメソッドに大きく依存するサイトではパフォーマンスが低下します。 Response.Redirect を使用する必要がある場合は、Response.Redirect(url, false)を呼び出します。これは Response.End を呼び出さないため、スローしません。 欠点は、 Response.Redirect(url, false) の呼び出しに続くユーザー コードが実行されるということです。 静的 HTML ページを使用してリダイレクトすることもできます。 Microsoft サポート技術情報の記事 312629 では、さらに詳しく説明します。

    この非常に便利なパフォーマンス カウンターを監視するだけでなく、管理者に問題を警告するために 、Application_Error イベントを使用する必要があります。

    しきい値: RPS の 5%。 これより大きい値を調査し、必要に応じて新しいしきい値を設定する必要があります。

.NET CLR 読み込みカウンター

_Global_ カウンター インスタンスは、すべてのマネージド プロセスによって更新されるため、これらのパフォーマンス カウンターでは使用しないでください。 代わりに、aspnet_wp インスタンスを使用します。

  • 現在の AppDomains。 プロセスに読み込まれた AppDomain の現在の数。 このカウンターの値は、Web アプリケーションの数に 1 を加えた値と同じである必要があります。 追加の AppDomain が既定のドメインです。

  • 現在のアセンブリ。 プロセスに読み込まれたアセンブリの現在の数。 既定では、ディレクトリ内の ASPX ファイルと ASCX ファイルは "バッチ" コンパイルされます。 これにより、通常、依存関係に応じて 1 から 3 つのアセンブリが生成されます。 たとえば、ASCX ファイルに解析時の依存関係を持つ ASPX ページがある場合、通常は 2 つのアセンブリが生成されます。 一方には ASPX ファイル、もう 1 つは ASCX ファイルが含まれます。 解析時の依存関係には、%@ インポート %、%@ 参照 %、%@ register %>> ディレクティブによって<作成されたものが含まれます。<<> LoadControl メソッドを介して読み込まれたコントロールでは、解析時の依存関係は作成されません。 global.asax は単独でアセンブリにコンパイルされることに注意してください。

    場合によっては、読み込まれたアセンブリの数が異常に多い場合に、過剰なメモリ消費が発生します。 たとえば、ニュース記事を表示するサイトは、各記事で使用される 1 つの ASPX ファイルよりも、データベースからニュースを取得する少数の ASPX ファイルを使用した方がパフォーマンスが向上します。 サイト デザイナーは、コンテンツを動的に生成し、キャッシュを利用し、ASPX ページと ASCX ページの数を減らすようにする必要があります。

    アセンブリを AppDomain からアンロードすることはできません。 過剰なメモリ消費を防ぐために、再コンパイルの数 (ASPX、ASCX、ASAX) がコンパイル numRecompilesBeforeAppRestart=/>で<指定された制限を超えると、AppDomain がアンロードされます。 %@ ページ debug<=%> 属性が true に設定されている場合、またはコンパイル debug=/> が true に設定されている場合<、バッチ コンパイルは無効になります。

  • ローダー ヒープ内のバイト数。 すべての AppDomain にわたってクラス ローダーによってコミットされたバイト数。 このカウンターは安定した状態に達する必要があります。 このカウンターが継続的に増加している場合は、"現在のアセンブリ" カウンターを監視します。 AppDomain ごとに読み込まれるアセンブリが多すぎる可能性があります。

.NET CLR メモリ カウンター

_Global_ カウンター インスタンスは、すべてのマネージド プロセスによって更新されるため、これらのパフォーマンス カウンターでは使用しないでください。 代わりに、aspnet_wp インスタンスを使用します。

  • # すべてのヒープのバイト数。 マネージド オブジェクトによってコミットされたバイト数。 これは、ラージ オブジェクト ヒープとジェネレーション 0、1、および 2 ヒープの合計です。 これらのメモリ領域の種類はMEM_COMMITです ( VirtualAlloc のプラットフォーム SDK ドキュメントを参照してください)。 このカウンターの値は、プロセスのすべてのMEM_COMMITリージョンをカウントする Process\Private Bytes の値より常に小さくなります。 プライベート バイトから # すべてのヒープのバイト数を引いた値は、アンマネージド オブジェクトによってコミットされたバイト数です。 過剰なメモリ使用量の調査の最初の手順は、それがマネージド オブジェクトとアンマネージド オブジェクトのどちらで使用されているかを判断することです。

    マネージド メモリの過剰な使用量を調査するには、WINDBG.EXEとSOS.DLLをお勧めします。この詳細については、「.NET Framework アプリケーションの運用デバッグ」を参照してください。 SOS.DLLには、マネージド ヒープ内のオブジェクトの数、サイズ、および種類を一覧表示する "!dumpheap –stat" コマンドがあります。 "!dumpheap –mt" を使用してオブジェクトのアドレスを取得し、"!gcroot" を使用してそのルートを確認できます。 コマンド "!eeheap" は、マネージド ヒープのメモリ使用量の統計情報を示します。

    メモリ使用量を診断するためのもう 1 つの便利なツールは、以下で詳しく説明する CLR プロファイラーです。

    一般に、次の場合には、マネージド メモリの使用量が過度に多くなります。

    1. 大容量のデータ セットをメモリに読み込んだ。
    2. 多数のキャッシュ エントリを作成した。
    3. 大きなファイルをアップロードまたはダウンロードした。
    4. ファイルの解析時に正規表現または文字列を過度に使用した。
    5. 過剰な ViewState。
    6. セッション状態のデータが大きすぎる。または、セッション数が多すぎる。

  • # Gen 0 コレクション。 ジェネレーション 0 のオブジェクトがガベージ コレクションされた回数。 存続するオブジェクトは、ジェネレーション 1 に昇格されます。 コレクションは、オブジェクトを割り当てるために会議室が必要な場合、または System.GC.Collect を呼び出してコレクションを強制的に実行する場合に実行されます。 上位の世代を含むコレクションは、下位の世代のコレクションの前に存在するため、時間がかかります。 第 2 世代コレクションの割合を最小限に抑えようとします。 経験則として、ジェネレーション 0 コレクションの数は、ジェネレーション 1 コレクションの数の 10 倍にし、世代 1 と 2 の場合も同様に大きくする必要があります。 # Gen N Collections カウンターと % Time in GC カウンターは、過剰な割り当てによって発生するパフォーマンスの問題を特定するのに最適です。 パフォーマンスを向上させるために実行できる手順については、GC の %Time の説明を参照してください。

  • # Gen 1 コレクション。 ジェネレーション 1 のオブジェクトがガベージ コレクションされた回数。 存続するオブジェクトは、ジェネレーション 2 に昇格されます。

    しきい値: # Gen 0 コレクションの値の 1/10。 適切に実行されるアプリケーションは、# Gen 0 Collections カウンターの説明に記載されている経験則に従います。

  • # Gen 2 コレクション。 ジェネレーション 2 オブジェクトがガベージ コレクションされた回数。 第 2 世代が最も高いため、コレクションに残るオブジェクトは第 2 世代に残ります。 Gen 2 のコレクションは、特に Gen 2 ヒープのサイズが過剰な場合に非常にコストがかかる場合があります。

    しきい値: # Gen 1 コレクションの 10 分の 1 の値。 適切に実行されるアプリケーションは、# Gen 0 Collections カウンターの説明に記載されている経験則に従います。

  • % Time in GC。 最後のガベージ コレクションの実行に費やされた時間の割合。 5% 以下の平均値は正常と見なされますが、これより大きなスパイクは珍しいことではありません。 ガベージ コレクション中にすべてのスレッドが中断されることに注意してください。

    GC の時間が長くなる最も一般的な原因は、要求ごとに割り当てが多すぎる場合です。 2 番目に一般的な原因は、大量のデータを ASP.NET キャッシュに挿入し、それを削除して再生成し、数分ごとにキャッシュに再挿入することです。 多くの場合、割り当てを大幅に削減するために行うことができる小さな変更があります。 たとえば、文字列連結は、連結された文字列をガベージ コレクションする必要があるため、要求ごとにコストがかかる場合があります。 適切な初期容量を持つ StringBuilder は、文字列連結よりも優れたパフォーマンスを発揮します。 ただし、StringBuilder もガベージ コレクションする必要があります。不適切に使用すると、内部バッファーのサイズが変更されるため、予想よりも多くの割り当てが発生する可能性があります。 各文字列に 対して Response.Write を複数回呼び出すと、StringBuilder と組み合わせるよりもパフォーマンスが向上するため、StringBuilder altogther を回避できる場合は、実行してください。

    多くの場合、アプリケーションは応答の生成中に StringBuilder または MemoryStream にデータを一時的に格納します。 要求ごとにこの一時ストレージを再作成する代わりに、文字配列またはバイト配列の再利用可能なバッファー プールを補完することを検討してください。 バッファー プールは、 GetBuffer ルーチンと ReturnBuffer ルーチンを持つオブジェクトです。 GetBuffer ルーチンは、バッファーの内部ストアからバッファーを返そうとしますが、ストアが空の場合は新しいバッファーを作成します。 ReturnBuffer ルーチンは、格納されているバッファーの最大数にまだ達していない場合は、ストアにバッファーを返しますが、それ以外の場合は解放します。 このバッファー プールの実装の欠点は、スレッド セーフのためにロックが必要であるという点です。 または、 HttpContext.ApplicationInstance を使用して global.asax で定義されたインスタンス フィールドにアクセスすることで、ロックのパフォーマンスへの影響を回避できます。 パイプライン インスタンスごとに global.asax のインスタンスが 1 つ存在するため、フィールドには一度に 1 つの要求からしかアクセスできないため、再利用可能な文字またはバイト バッファーを格納するのに適しています。

    GC の時間の割合を短縮するには、割り当てパターンを把握する必要があります。 CLR プロファイラーを使用して、1 つの要求または軽いストレスを最大で数分間プロファイリングします。 (これらのツールは侵襲性があり、producton で使用するためのものではありません。割り当てグラフ ビューには、各オブジェクトの種類に割り当てられたメモリの合計と、割り当てを実行した呼び出し履歴が表示されます。 これを使用して、過剰な割り当てを減らします。 [サイズ別ヒストグラム] ビュー ([表示] メニューの [ヒストグラム割り当て型] を選択) は、割り当てられたオブジェクトのサイズをまとめたものです。 85,000 バイトを超える有効期間の短いオブジェクトは割り当てないでください。 これらのオブジェクトは大きなオブジェクト ヒープに割り当てられ、収集コストが高くなります。 [サイズ別ヒストグラム] ビューでは、マウスでオブジェクトを選択し、右クリックして割り当てたユーザーを確認できます。 割り当ての削減は、コードの変更とプロファイリングの反復的なプロセスです。

    しきい値: 平均 5% 以下。これよりも短い有効期間のスパイクが一般的です。 これより大きい平均値を調査する必要があります。 必要に応じて、新しいしきい値を設定する必要があります。

ASP.NET カウンター

このカテゴリのパフォーマンス カウンターは、w3svc サービスが開始されたときにのみ 0 にリセットされます。

  • アプリケーションの再起動。 アプリケーションの再起動の数。 アプリケーション ドメインの再作成とページの再コンパイルには時間がかかるため、予期しないアプリケーションの再起動を調査する必要があります。 アプリケーション ドメインは、次のいずれかが発生するとアンロードされます。

    • machine.config、 web.config、または global.asax の変更。
    • アプリケーションの bin ディレクトリまたはその内容の変更。
    • コンパイルの数 (ASPX、ASCX、または ASAX) が、コンパイル numRecompilesBeforeAppRestart=/>で<指定された制限を超えた場合。
    • 仮想ディレクトリの物理パスの変更。
    • コード アクセス セキュリティ ポリシーの変更。
    • Web サービスが再起動されます。

    運用環境の Web ファームでは、パフォーマンスと信頼性を最大限に高めるために、コンテンツを更新する前にサーバーをローテーションから削除することをお勧めします。 運用環境の 1 つの Web サーバーの場合、サーバーの負荷が高い間にコンテンツを更新できます。 サポート技術情報の記事810281に記載されている修正プログラムは、アプリケーションの再起動後にエラーが発生したユーザーにとって重要です。たとえば、"別のプロセスで使用されているため、ファイル FileName <> にアクセスできません" のようなエラーで違反を共有する場合などです。

    ウイルス対策ソフトウェアとアプリケーションの再起動に関する問題は、「サポート技術情報の記事 820746 : 修正: 一部のウイルス対策プログラムにより 、Web アプリケーションが v1.0 の場合に予期せず再起動する可能性がある」および「 サポート技術情報の記事 821438 for v1.1」で修正されています。

    しきい値: 0。 完璧な世界では、アプリケーション ドメインはプロセスの一生を生き残ります。 過剰な値を調査し、必要に応じて新しいしきい値を設定する必要があります。

  • 実行中のアプリケーション。 実行されているアプリケーションの数。

  • 現在の を要求します。 ASP.NET ISAPI によって現在処理されている要求の数。 これには、クライアントに書き込まれるキュー、実行中、または待機しているものも含まれます。 このパフォーマンス カウンターは、サポート技術情報の記事 329959で説明されている SP3 より前の修正プログラムの ASP.NET の v1.0 に追加されました。

    このカウンターが processModel 構成セクションで定義されている requestQueueLimit を超えると、ASP.NET は要求の拒否を開始します。 requestQueueLimit は、aspnet_wpで実行されている場合は IIS 5.0 の ASP.NET に適用されますが、おそらく驚くべきことに、w3wp で実行されている場合は IIS 6.0 にも適用されることに注意してください。 IIS 6.0 で実行するときに、いくつかの processModel 構成設定が引き続き適用されるのはよく知られています。 これには、requestQueueLimit、responseDeadlockInterval、maxWorkerThreads、maxIoThreads、minWorkerThreads、minIoThreads が含まれます。 2003 年 6 月 1 日の修正プログラム ロールアップ パッケージ ASP.NET 1.1 で修正されたフレームワークの v1.1 のバグにより、IIS 6.0 で実行するときに、ASP.NET が無限の数の要求を処理できました。 この修正により、現在の要求が requestQueueLimit を超えると、ASP.NET は要求を拒否します。

    従来の ASP アプリケーションの場合、Requests Queued は要求が拒否されるタイミングに関する警告を提供します。 ASP.NET の場合、現在の要求とアプリケーション キューの要求は、この機能を提供します。このカウンターは、ASP.NET デッドロック検出メカニズムでも使用されます。 Requests Current が 0 より大きく、processModel responseDeadlockInterval=/>で<指定された制限を超える期間、ワーカー プロセスから応答が受信されていない場合、プロセスは終了し、新しいプロセスが開始されます。 サポート技術情報の記事の328267で説明されている SP3 より前の修正プログラムでは、現在の要求が processModel/> 構成セクションで<指定された maxWorkerThreads と maxIoThreads の合計を超える必要があるため、アルゴリズムが変更されました。 既定では、要求の実行タイムアウトは 90 秒であり、意図的に responseDeadlockInterval よりも小さいことに注意してください。 要求の実行タイムアウトは、httpRuntime executionTimeout=/> 構成設定または Server.ScriptTimeout プロパティを使用して<変更できますが、常に responseDeadlockInterval より小さくする必要があります。

  • 要求の実行時間。 最後の要求の実行にかかった時間 (ミリ秒)。 フレームワークのバージョン 1.0 では、ワーカー プロセスが要求を受け取ると実行時間が開始され、ASP.NET ISAPI が IIS にHSE_REQ_DONE_WITH_SESSIONを送信すると停止します。 IIS バージョン 5 の場合、これにはクライアントへの応答の書き込みにかかった時間が含まれますが、IIS バージョン 6 の場合、応答バッファーは非同期的に送信されるため、クライアントへの応答の書き込みにかかった時間は含まれません。 したがって、IIS バージョン 5 では、ネットワーク接続が遅いクライアントでは、このカウンターの値が大幅に増加します。

    フレームワークのバージョン 1.1 では、要求の HttpContext が作成されると実行時間が開始され、応答が IIS に送信される前に停止します。 ユーザー コードが HttpResponse.Flush を呼び出さないと仮定すると、IIS またはクライアントにバイトを送信する前に実行時間が停止することを意味します。

    ASP.NET\Request Execution Time はインスタンス カウンターであり、非常に揮発性です。 一方、最後のバイトまでの時間 (TTLB) を簡単に平均化し、一定期間のパフォーマンスのより良い見積もりを計算するために使用できます。 TTLB は、マネージド コードで記述された単純な HTTP クライアントを使用して計算することも、TTLB を計算できる多くの HTTP クライアントの 1 つ (Application Center Test (ACT) など) を使用することもできます。

    コンパイル debug=/> が TRUE に設定されている場合<、バッチ コンパイルは無効<になり、httpRuntime executionTimeout=/> 構成設定と Server.ScriptTimeout の呼び出しは無視されることに注意してください。 デバッグ ページの<要求は理論的には永遠に実行されるため、processModel responseDeadlockInterval=/> 設定が Infinite に設定されていない場合、この問題が発生する可能性があります。

    しきい値: N.A. このカウンターの値は安定している必要があります。 エクスペリエンスは、特定のサイトのしきい値を設定するのに役立ちます。 プロセス モデルが有効になっている場合、要求の実行時間にはクライアントへの応答の書き込みに必要な時間が含まれるため、クライアントの接続の帯域幅によって異なります。

  • キューに入った要求。 現在キューに登録されている要求の数。 IIS 5.0 で実行している場合、inetinfo と aspnet_wpの間にキューがあり、仮想ディレクトリごとに 1 つのキューがあります。 IIS 6.0 で実行している場合、ネイティブ コードからマネージド ThreadPool に要求がポストされるキューと、各仮想ディレクトリのキューがあります。 このカウンターには、すべてのキューの要求が含まれます。 inetinfo と aspnet_wp の間のキューは、要求が一方のプロセスから他方のプロセスに送信される名前付きパイプです。 このキュー内の要求の数は、aspnet_wp プロセスで使用可能な I/O スレッドが不足している場合に増加します。 IIS 6.0 では、受信要求があり、ワーカー スレッドが不足すると増加します。

    Requests Current カウンターが processModel requestQueueLimit=/を<超えると、要求は拒否されることに注意してください>。 多くの人は、これは Requests Queued カウンターが requestQueueLimit を超えたときに発生すると考えていますが、これは当てはまれません。 この制限を超えると、要求は 503 状態コードで拒否され、"サーバーがビジー状態です" というメッセージが表示されます。この理由で要求が拒否された場合、その要求はマネージド コードに到達せず、エラー ハンドラーには通知されません。 通常、これは、サーバーの負荷が非常に高い場合にのみ問題になりますが、1 時間ごとに "バースト" 負荷が発生すると、これが発生する可能性もあります。 通常とは異なるバースト読み込みのシナリオでは、 サポート技術情報の記事の810259で説明されている修正プログラムに関心がある場合があります。これにより、I/O スレッドの最小数を既定の 1 CPU あたり 1 から増やせるようにすることができます。

    各仮想ディレクトリには、ワーカー スレッドと I/O スレッドの可用性を維持するために使用するキューがあります。 このキュー内の要求の数は、使用可能なワーカー スレッドまたは使用可能な I/O スレッドの数が httpRuntime minFreeThreads=/> で<指定された制限を下回った場合に増加します。 httpRuntime appRequestQueueLimit=/> で<指定された制限を超えると、要求は 503 状態コードで拒否され、クライアントは "Server too busy" というメッセージを含む HttpException を受け取ります。

    このカウンター自体は、パフォーマンスの問題を明確に示すものではありません。また、要求がいつ拒否されるかを判断するために使用することもできません。 サポート技術情報の記事329959では、この問題に対処するために 2 つの新しいパフォーマンス カウンターが導入されました。現在の要求とアプリケーション キュー内の要求。 これら 2 つのカウンターの説明と、拒否された要求に関する説明を参照してください。

  • 要求が拒否されました。 拒否された要求数。 キューの制限のいずれかを超えると、要求は拒否されます (「キューに登録された要求」の説明を参照してください)。 要求は、さまざまな理由で拒否できます。 低速な SQL サーバーなどのバックエンド待機時間の前には、パイプライン インスタンスの数が急激に増加し、CPU 使用率と要求数/秒が減少することがよくあります。最終的に要求が拒否されるプロセッサまたはメモリの制約により、負荷が高い時間帯にサーバーが過負荷になる可能性があります。

    アプリケーションの設計により、要求の実行時間が過剰になる可能性があります。 たとえば、バッチ コンパイルは、ページの最初の要求を受信したときに、ディレクトリ内のすべてのページが 1 つのアセンブリにコンパイルされる機能です。 ディレクトリに数百ページある場合、このディレクトリへの最初の要求の実行に時間がかかる場合があります。 コンパイル batchTimeout=/> を超えた場合<、バッチコンパイルはバックグラウンド スレッドで続行され、要求されたページは個別にコンパイルされます。 バッチ コンパイルが成功した場合、アセンブリはディスクに保持され、アプリケーションの再起動後に再利用できます。 ただし、global.asax、web.config、machine.config、またはアプリケーションの bin フォルダー内のアセンブリが変更された場合、依存関係の変更によりバッチ コンパイル プロセスが再度実行されます。

    大規模なサイトを慎重に設計すると、パフォーマンスに大きな影響を与える可能性があります。 この場合は、クエリ文字列データに基づいて動作が異なるページを少数にすることをお勧めします。 一般に、要求の実行時間を最小限に抑える必要があります。これは、Web サイトから 1 つ以上のページを要求する HTTP クライアントを使用して、最後のバイト (TTLB) までの平均時間によって最適に監視されます。

    拒否された要求の原因を検出するには、次のパフォーマンス カウンターが最適です。

    • Process\% Processor Time
    • Process\Private Bytes
    • Process\Thread Count
    • Web サービス\ISAPI 拡張機能要求/秒
    • ASP.NET\Requests Current
    • ASP.NET\Requests Queued
    • ASP.NET\要求の待機時間
    • ASP.NET Applications\Pipeline Instance Count
    • アプリケーション キューでのアプリケーション\要求の ASP.NET

    しきい値: 0。 このカウンターの値は 0 である必要があります。 これより大きい値を調査する必要があります。

  • 要求の待機時間。 inetinfo と aspnet_wpの間に存在するキュー (名前付きパイプ) で最新の要求が待機に費やしたミリ秒数 (キューに入っている要求の説明を参照)。 これには、アプリケーション キューでの待機に費やされた時間は含まれません。

    しきい値: 1000。 平均要求では、キューで待機するのに 0 ミリ秒を費やす必要があります。

  • 実行中のワーカー プロセス。 aspnet_wpワーカー プロセスの現在の数。 短時間、新しいワーカー プロセスと置き換えられるワーカー プロセスが共存する場合があります。 まれですが、終了中にデッドロックが処理されることがあります。 これが疑われる場合は、ツールを使用してワーカー プロセスのインスタンス数を監視することを検討してください。 または、メモリ\使用可能な Mbytes パフォーマンス カウンターを使用できます。これらのぶら下げプロセスではメモリが消費されるためです。

    しきい値: 2。 前のワーカー プロセスのシャットダウン中に、2 つのインスタンスが存在する可能性があります。 webGarden が有効になっている場合、しきい値は #CPUs に 1 を加えたものにする必要があります。 これより大きい値は、非常に短い期間内に過剰なプロセスの再起動を示している可能性があります。

  • ワーカー プロセスの再起動。 aspnet_wpプロセスの再起動の数。

    しきい値: 1。 プロセスの再起動はコストがかかり、望ましくありません。 値は、プロセス モデルの構成設定と、予期しないアクセス違反、メモリ リーク、デッドロックに依存します。 aspnet_wp再起動すると、アプリケーション イベント ログ エントリに理由が示されます。 アクセス違反またはデッドロックが発生した場合、要求は失われます。 プロセス モデルの設定を使用してプロセスをプリエンプティブにリサイクルする場合は、適切なしきい値を設定する必要があります。

ASP.NET アプリケーション カウンター

このカテゴリのパフォーマンス カウンターは、アプリケーション ドメインまたは Web サービスが再起動されると 0 にリセットされます。

  • キャッシュの合計エントリ数。 キャッシュ内の現在のエントリ数 (User と Internal の両方)。 内部的には、ASP.NET はキャッシュを使用して、構成オブジェクト、保持されたアセンブリ エントリ、 MapPath メソッドによってマップされたパス、インプロセス セッション状態オブジェクトなど、作成コストの高いオブジェクトを格納します。

    メモ パフォーマンス カウンターの "キャッシュ合計" ファミリは、インプロセス セッション状態に関する問題を診断するのに役立ちます。 キャッシュに格納するオブジェクトが多すぎると、多くの場合、メモリ リークの原因になります。

  • キャッシュの合計ヒット率。 すべてのキャッシュ要求 (ユーザーと内部の両方) のヒット対ミス率の合計。

  • キャッシュの総離職率。 1 秒あたりのキャッシュへの追加と削除の数 (ユーザーと内部の両方)。 離職率が高い場合は、品目が迅速に追加および削除され、コストがかかる可能性があることを示します。

  • API エントリをキャッシュします。 ユーザー キャッシュ内の現在のエントリの数。

  • キャッシュ API ヒット率。 ユーザー キャッシュ要求のヒット対ミス率の合計。

  • キャッシュ API の離職率。 1 秒あたりのユーザー キャッシュへの追加と削除の数。 離職率が高い場合は、品目が迅速に追加および削除され、コストがかかる可能性があることを示します。

  • 出力キャッシュ エントリ。 出力キャッシュ内の現在のエントリの数。

  • 出力キャッシュ ヒット率。 出力キャッシュ要求のヒット対ミス率の合計。

  • 出力キャッシュの回転率。 1 秒あたりの出力キャッシュへの追加と削除の数。 離職率が高い場合は、品目が迅速に追加および削除され、コストがかかる可能性があることを示します。

  • パイプライン インスタンス数。 アクティブなパイプライン インスタンスの数。 パイプライン インスタンス内で実行できる実行スレッドは 1 つだけであるため、この数は、特定のアプリケーションで処理される同時要求の最大数を示します。 パイプライン インスタンスの数は安定している必要があります。 突然の増加は、バックエンドの待機時間を示しています (上記の「拒否された要求」の説明を参照してください)。

  • 合計コンパイル数。 コンパイルされた ASAX、ASCX、ASHX、ASPX、または ASMX ファイルの数。 これは、生成されたアセンブリの数ではなく、コンパイルされたファイルの数です。 アセンブリはディスクに保持され、作成時刻、最終書き込み時刻、またはファイルの依存関係の長さが変更されるまで再利用されます。 ASPX ページの依存関係には、global.asax、web.config、machine.config、bin フォルダー内の依存アセンブリ、ページによって参照される ASCX ファイルが含まれます。 ファイルの依存関係を変更せずにアプリケーションを再起動すると、保存されているアセンブリはコンパイルを必要とせずに再読み込みされます。 このパフォーマンス カウンターは、ファイルが最初に解析され、アセンブリにコンパイルされた場合にのみインクリメントされます。

    既定では、バッチ コンパイルは有効になっていますが、このカウンターは、作成されるアセンブリの数に関係なく、解析されてアセンブリにコンパイルされるファイルごとに 1 回インクリメントされます。

    コンパイルに失敗した場合、カウンターはインクリメントされません。

  • 前処理中のエラー。 構成エラーと解析エラーの合計数。 このカウンターは、構成エラーまたは解析エラーが発生するたびにインクリメントされます。 構成エラーはキャッシュされますが、エラーが発生するたびにカウンターがインクリメントされます。

    メモ サーバーが正常かどうかを判断するために、"エラー" パフォーマンス カウンターのみに依存しないでください。 AppDomain がアンロードされると、0 にリセットされます。 ただし、特定の問題をより深く掘り下げるのに使用できます。 一般に、管理者に問題を通知するには、 Application_Error イベントを使用します。

  • コンパイル中のエラー。 コンパイル エラーの合計数。 応答がキャッシュされ、このカウンターは、ファイルの変更によって再コンパイルが強制されるまで 1 回だけインクリメントされます。 イベントを発生させるカスタム エラー処理を実装します。

  • 実行中のエラー。 実行時エラーの合計数。

  • 実行中に処理されないエラー。 実行時の未処理の例外の合計数。 これには次は含まれません。

    1. イベント ハンドラーによってクリアされたエラー (たとえば、 Page_Error や Application_Error)。
    2. リダイレクト ページによって処理されるエラー。
    3. try/catch ブロック内で発生するエラー。

  • 実行中に処理されないエラー/秒。実行時の 1 秒あたりの未処理の例外の合計数。

  • エラーの合計。 前処理中のエラー、コンパイル中のエラー、実行中のエラーの合計。

  • エラーの合計/秒。前処理中のエラー、コンパイル中のエラー、および 1 秒あたりの実行中のエラーの合計。

  • 実行中の要求。 現在実行中の要求の数。 このカウンターは、 HttpRuntime が要求の処理を開始したときにインクリメントされ、 HttpRuntime が要求を完了した後にデクリメントされます。 フレームワークの v1.1 では、 2003 年 6 月 1.1 日の修正プログラム ロールアップ パッケージ ASP.NET 1.1 で修正される、このパフォーマンス カウンターにバグがあります。 残念ながら、このバグはサポート技術情報の記事では説明されていません。 修正の前に、カウンターにはクライアントへの応答の書き込みにかかった時間が含まれていました。

  • アプリケーション キュー内の要求。 アプリケーション要求キュー内の要求の数 (上記の「キューに入った要求」の説明を参照)。 [現在の要求] に加えて、アプリケーション キューの要求には、要求が拒否されるタイミングに関する警告が表示されます。 仮想ディレクトリが 2 つしかない場合は、既定の appRequestQueueLimit を 200 または 300 に増やすと、特に負荷の高い低速アプリケーションに適している可能性があります。

  • 要求が見つかりません。 リソースに対する要求の数が見つかりません。

  • 要求が承認されていません。 不正アクセスが原因で失敗した要求の数。

  • 要求がタイムアウトしました。タイムアウトした要求の数。

  • 要求は成功しました。 正常に実行された要求の数。

  • 要求の合計。 アプリケーションが開始されてからの要求の数。

  • Requests/Sec。1 秒あたりに実行された要求の数。 アプリケーションの再起動の影響を受けないため、"Web Service\ISAPI 拡張機能要求/秒" が好きです。

プロセス カウンター

これらのカウンターを使用すると、対象のプロセスはaspnet_wpおよび inetinfo になります。

  • % プロセッサ時間。 このプロセスのスレッドがプロセッサの使用に費やした時間の割合。

    しきい値: 70%。 これより長い期間の値は、ハードウェアを購入するか、アプリケーションを最適化する必要があることを示します。

  • ハンドル数。

    しきい値: 10000。 aspnet_wpのハンドル数は 2000 で、10,000 は許容範囲をはるかに超えています。 すべてのプロセスの総ハンドル数が約 40,000 を超えると、パフォーマンスが著しく低下します。これは、IIS に対するサービス拒否攻撃中に完全に達成できます。

  • プライベート バイト数。 このプロセスが所有するコミット済みメモリの現在のサイズ (バイト単位)。 メモリ リークは、プライベート バイトの一貫した長期増加によって識別されます。 これは、メモリ リークを検出するための最適なパフォーマンス カウンターです。

    IIS 5.0 で実行する場合は、processModel memoryLimit=/> 構成セクションでプライベート バイトの<メモリ制限を設定する必要があります。 IIS 6.0 で実行する場合は、IIS マネージャーでメモリ制限を設定する必要があります。 アプリケーション プールの [プロパティ ] を開き、[ リサイクル ] タブ で [最大使用メモリ数 (メガバイト)] に制限を指定します。 この制限は Private Bytes に対応します。 ワーカー プロセスのプライベート バイト数をメモリ制限と比較して、プロセスをリサイクルするタイミングを決定します。 System.Web.Caching.Cache では、プライベート バイトとメモリ制限も使用して、キャッシュから項目を削除するタイミングを決定するため、プロセスのリサイクルを回避します。 ページングを回避するには、特にメモリ消費量が過剰であるために新しいプロセスが古い RAM を置き換える場合は、物理 RAM の 60% のメモリ制限をお勧めします。 サポート技術情報の記事330469では、多数の実行中のプロセスを持つサーバーでプライベート バイトの監視に失敗する ASP.NET の問題が解決されることに注意してください。 この修正プログラムを使用すると、実行中のプロセスが多数ある場合にキャッシュ メモリ マネージャーが正しく機能することもできます。

    キャッシュ メモリ マネージャーとプロセス リサイクル機能が適切に機能するように、大量の物理 RAM を持つマシンのメモリ制限を調整することが重要です。 たとえば、既定のメモリ制限を使用している物理 RAM が 4 ギガバイト (GB) のサーバーがあるとします。 これは問題です。 物理 RAM の 60% は 2.4 GB で、既定の仮想アドレス空間の 2 GB を超えています。 では、メモリ制限は何に設定する必要がありますか?

    考慮すべき点がいくつかあります。まず、"Process\Virtual Bytes" が仮想アドレス空間の制限 (通常は 2 GB) の 600 MB 以内である場合、 OutOfMemoryException が発生する可能性が大幅に高まり始めます。次に、テストでは"Process\Virtual Bytes" が "Process\Private Bytes" よりも 600 MB 以下大きくなることが示されています。 この違いは、GC によって維持されるMEM_RESERVE領域の一部が原因であり、必要に応じてより多くのメモリをすばやくコミットできます。 まとめると、"Process\Private Bytes" が 800 MB を超えると、 OutOfMemoryException が発生する可能性が高くなります。 この例では、マシンには 4 GB の物理 RAM があるため、メモリ不足状態を回避するには、メモリ制限を 20% に設定する必要があります。 これらの数値を試してマシン上のメモリ使用量を最大化することもできますが、安全に再生する場合は、この例の数値が機能します。

    要約すると、メモリ制限を物理 RAM の 60% または 800 MB 以下に設定します。 v1.1 では 3 GB の仮想アドレス空間がサポートされているため、boot.iniに /3 GB を追加すると、上限として 800 MB ではなく 1,800 MB を安全に使用できます。

    テストを実行するときに、GC を強制してマネージド メモリを安定させる場合は、 System.GC.GetTotalMemory(true) を 1 回呼び出すことができます。 このメソッドは GC を呼び出します 。 メモリが 5% 以内で安定するまで、Collect と WaitForPendingFinalizers() を繰り返し収集します。

    しきい値: 物理 RAM の最小 60% と 800 MB。 物理 RAM 全体の 60% を超える値は、特にアプリケーションとプロセスの再起動中にパフォーマンスに影響を与え始めます。 OutOfMemoryException の信頼性は、仮想アドレス空間の制限が 2 GB のプロセスでプライベート バイト数が 800 MB を超えると大幅に増加します。

  • スレッド数。 このプロセスでアクティブなスレッドの数。 負荷が高すぎると、スレッド数が増えることがよくあります。

    しきい値: 75 + ((maxWorkerThread + maxIoThreads) * #CPUs) aspcompat モードを使用する場合は、しきい値を増やす必要があります 。しきい値: 75 + ((maxWorkerThread + maxIoThreads) * #CPUs * 2)。

  • 仮想バイト。 このプロセスの仮想アドレス空間の現在のサイズ (バイト単位)。

    boot.iniの /3 GB スイッチを使用して 3 GB のアドレス空間が有効になっていない限り、ユーザー モード プロセスの仮想アドレス空間の制限は 2 GB です。 この制限に近づくとパフォーマンスが低下し、通常はプロセスまたはシステムクラッシュが発生します。 アドレス空間は、2 GB または 3 GB の制限に近づくと断片化するため、それぞれ 1.4 GB または 2.4 GB の保守的なしきい値をお勧めします。 ここで問題が発生している場合は、 System.OutOfMemoryException がスローされ、プロセスがクラッシュする場合とクラッシュしない場合があります。

    IIS 6.0 で実行する場合は、IIS マネージャーで仮想メモリの制限を設定できます。 ただし、これを不適切に設定すると、ASP.NET に問題が発生する可能性があります。 ASP.NET、プライベート バイト数の制限を超えないようにキャッシュから項目を削除しますが、この決定では、アルゴリズムでは Private Bytes と Private Bytes の制限が使用されます。 仮想バイト数または仮想バイト数の制限は監視されません。 仮想バイトとプライベート バイトの差が通常 600 MB 以下であることを考えると、仮想メモリリークや断片化の可能性が懸念される場合は、仮想バイト数の制限をプライベート バイト数の制限より 600 MB 大きい値に設定できます。 これが望ましい場合は、アプリケーション プールの [プロパティ] の [リサイクル] タブにある [最大仮想メモリ (メガバイト単位)] に制限を設定します。

    バージョン 1.0 の Framework では、ワーカー プロセスまたは状態サービスで 3 GB のアドレス空間がサポートされていません。 ただし、inetinfo.exe内で 3 GB のアドレス空間を有効にする手順については、 サポート技術情報の記事 320353を参照してください。 バージョン 1.1 では、ワーカー プロセスと状態サービス用に 3 GB のアドレス空間が完全にサポートされています。

    しきい値: 仮想アドレス空間のサイズより 600 MB 小さい (1.4 または 2.4 GB)。

プロセッサ カウンター

  • % プロセッサ時間。 すべてのスレッドがプロセッサを使用して費やした時間の割合。

    しきい値: 70%。 これより長い期間の値は、ハードウェアを購入するか、アプリケーションを最適化する必要があることを示します。

メモリ カウンター

  • 使用可能な MB。 使用可能な物理 RAM の量。

    しきい値: 物理 RAM の 20%。 これより小さい値は調査する必要があり、ハードウェアを購入する必要があることを示している可能性があります。

システム カウンター

  • コンテキスト スイッチ/秒。プロセッサがスレッド コンテキストを切り替える速度。 数値が大きい場合は、ロックの競合が大きいか、ユーザーモードとカーネルモードの間の遷移を示している可能性があります。 コンテキスト スイッチ/秒は、スループット、負荷、CPU の数に応じて直線的に増加する必要があります。 指数関数的に増加すると、問題があります。 さらに調査するには、プロファイラーを使用する必要があります。

Web サービス カウンター

  • 現在の接続。 このカウンターのしきい値は、要求の種類 (ISAPI、CGI、静的 HTML など)、CPU 使用率など、多くの変数に依存します。 しきい値は、エクスペリエンスを通じて開発する必要があります。
  • Total Method Requests/sec.主にパフォーマンスの問題を診断するためのメトリックとして使用されます。 静的ページが提供するページとaspnet_isapi.dllによってレンダリングされたページの割合を確認するには、これを "ASP.NET Applications\Requests/sec" と "Web Service\ISAPI Extension Requests/sec" と比較すると興味深い場合があります。
  • ISAPI 拡張機能要求/秒。主にパフォーマンスの問題を診断するためのメトリックとして使用されます。 これを "ASP.NET Applications\Requests/sec" および "Web Service\Total Method Requests/sec" と比較すると興味深い場合があります。これには、aspnet_isapi.dllだけでなく、すべての ISAPI 拡張機能への要求が含まれていることに注意してください。

まとめ

アプリケーションを稼働する前に注意深くストレスとパフォーマンステストを行うと、大きな頭痛を防ぐことができます。 多くの人々が遭遇する2つの大きなつまずきがあるようです。

  1. Web サイトで発生すると予想されるトラフィックと負荷をシミュレートできる HTTP クライアントを使用する必要があります。
  2. 運用環境とほぼ同じ環境でアプリケーション全体をテストする必要があります。

実際の Web サイト トラフィックをシミュレートするのは簡単ではありませんが、問題が発生するアプリケーションのほとんどは、十分なストレス テストを受けたことがないと正直に言えます。 この記事は、パフォーマンス カウンターを理解し、パフォーマンスを監視するための便利なツールをいくつか作成するのに役立ちます。 負荷を適用するには、Microsoft Visual Studio® .NET に含まれている Microsoft® Application Center Test (ACT) をお勧めします。 このストレス ツールの詳細については、 Microsoft Application Center Test 1.0 Visual Studio .NET Edition を参照してください。 また、Microsoft® Web アプリケーション ストレス ツール (WAST) もお勧めします。 これは TechNet から無料でダウンロードできます。 アプリケーションで ViewState を使用する場合は、WAST で応答を動的に解析できないため、ACT を使用する必要があります。

私はそれが運用環境について何であるか分かりませんが、それらについて特別なものは間違いなくあります。 「問題は生産現場でのみ発生する」という声明を聞いたことは数え切れません。通常、違いはアプリケーション自体です。 多くの場合、ラボでシミュレートできないアプリケーションの一部があります。 たとえば、広告サーバーをテストから除外したり、実際のデータベースをシミュレートするために使用されるデータベースが大きく異なったりします。 ネットワークまたは DNS の違いが原因である場合もあれば、サーバーが実行されるハードウェアの違いである場合もあります。

私は何年もの間、ASP.NET アプリケーションのパフォーマンスをデバッグして監視してきましたが、まだ助けが必要な場合があります。 この立場に立っている場合は、 ASP.NET Web サイト のフォーラムで回答を得られます。 ただし、実際にバインドされている場合は、そのサイトで提供されている連絡先情報を使用して Microsoft 製品サポート にお問い合わせください。 問題が Microsoft 製品の欠陥の結果であると Microsoft によって判断された場合、そのインシデントに対して課金されないことに注意してください。

このドキュメントには、アプリケーションの信頼性とパフォーマンスを確保するために必要なツールと情報が用意されていることを願っています。 ご不明な点がある場合は、 ASP.NET Web に投稿して、回答できるように最善を尽くします。 がんばってください。

著者について

Thomas Marquardt は、Microsoft の ASP.NET チームの開発者です。 2000 年の冬から、ASP.NET アプリケーションのパフォーマンスに関する問題のデバッグと調査を行っています。 Thomas は、Microsoft の ASP.NET 開発マネージャーである Dmitry Robsman に、長年にわたる何時間もの支援とガイダンスに感謝します。

© Microsoft Corporation. All rights reserved.