SignalR パフォーマンスSignalR Performance

提供者: Patrick Fletcherby Patrick Fletcher

Warning

このドキュメントは SignalR の最新バージョンはありません。This documentation isn't for the latest version of SignalR. 見てASP.NET Core SignalRします。Take a look at ASP.NET Core SignalR.

このトピックでは、ための設計、計測、および SignalR アプリケーションのパフォーマンスを向上する方法について説明します。This topic describes how to design for, measure, and improve performance in a SignalR application.

このトピックで使用されるソフトウェアのバージョンSoftware versions used in this topic

このトピックの以前のバージョンPrevious versions of this topic

SignalR の以前のバージョンについては、次を参照してください。以前のバージョンの SignalRします。For information about earlier versions of SignalR, see SignalR Older Versions.

意見やご質問Questions and comments

このチュートリアルの良い点に関するフィードバックや、ページ下部にあるコメントで改善できる点をお知らせください。Please leave feedback on how you liked this tutorial and what we could improve in the comments at the bottom of the page. チュートリアルに直接関係のない質問がある場合は、ASP.NET SignalR フォーラムまたはStackOverflow.comにて投稿してください。If you have questions that are not directly related to the tutorial, you can post them to the ASP.NET SignalR forum or StackOverflow.com.

SignalR パフォーマンスとスケーリングに最近行ったプレゼンテーションは、次を参照してください。 ASP.NET SignalR によるリアルタイムの Web スケールします。For a recent presentation on SignalR performance and scaling, see Scaling the Real-time Web with ASP.NET SignalR.

このトピックは、次のセクションで構成されています。This topic contains the following sections:

設計に関する考慮事項Design considerations

このセクションでは、不要なネットワーク トラフィックを生成することによってパフォーマンスが低下しないことを確認するには SignalR アプリケーションのデザイン時に実装できるパターンについて説明します。This section describes patterns that can be implemented during the design of a SignalR application, to ensure that performance is not being hindered by generating unnecessary network traffic.

メッセージの頻度を調整Throttling message frequency

を (リアルタイムのゲーム アプリケーションの場合) などの高頻度でメッセージを送信するアプリケーションであっても、ほとんどのアプリケーションは、1 秒間に複数のメッセージを送信する必要はありません。Even in an application that sends out messages at a high frequency (such as a realtime gaming application), most applications don't need to send more than a few messages a second. 各クライアントを生成するトラフィックの量を減らすためには、メッセージ ループを実装するキューおよび送信メッセージありませんより固定レートよりも頻繁に (つまり、メッセージ数まで送信されます 1 秒ごとに、その時点でのメッセージがある場合terval 送信する)。To reduce the amount of traffic that each client generates, a message loop can be implemented that queues and sends out messages no more frequently than a fixed rate (that is, up to a certain number of messages will be sent every second, if there are messages in that time interval to be sent). メッセージを (クライアントとサーバーの両方) から、一定のレートを調整するサンプル アプリケーションの場合、次を参照してください。 SignalR による高頻度リアルタイム メッセージングします。For a sample application that throttles messages to a certain rate (from both client and server), see High-Frequency Realtime with SignalR.

メッセージのサイズを縮小します。Reducing message size

SignalR メッセージのサイズを小さくには、シリアル化されたオブジェクトのサイズを小さきます。You can reduce the size of a SignalR message by reducing the size of your serialized objects. サーバー コードでは、転送する必要がないプロパティを格納しているオブジェクトを送信する場合は妨げられるこれらのプロパティを使用してシリアル化される、JsonIgnore属性。In server code, if you're sending an object that contains properties that don't need to be transmitted, prevent those properties from being serialized by using the JsonIgnore attribute. プロパティの名前がメッセージにも格納されています。使用してプロパティの名前を短縮できます、JsonProperty属性。The names of properties are also stored in the message; the names of properties can be shortened using the JsonProperty attribute. 次のコード サンプルでは、プロパティ名を短縮する方法と、クライアントに送信されてからプロパティを除外する方法を示しています。The following code sample demonstrates how to exclude a property from being sent to the client, and how to shorten property names:

.NET サーバー コードから、クライアントに送信されるデータを除外する JsonIgnore 属性とメッセージのサイズを小さく JsonProperty 属性を説明します。.NET server code that demonstrates the JsonIgnore attribute to exclude data from being sent to the client, and the JsonProperty attribute to reduce message size

using Newtonsoft.Json; 
using System; 
public class ShapeModel
{
    [JsonProperty("l")]
    public double Left { get; set; }
    [JsonProperty("t")]
    public double Top { get; set; }
    // We don't want the client to get the "LastUpdatedBy" property
    [JsonIgnore]
    public string LastUpdatedBy { get; set; }
}

読みやすさを維持するために、クライアント コードで保守性、プロパティの省略名は、わかりやすいにマップが変更された名、メッセージが受信されるとします。In order to retain readability/ maintainability in the client code, the abbreviated property names can be remapped to human-friendly names after the message is received. 次のコード サンプルに示します (マッピング) のメッセージ コントラクトを定義することより長いものを使用する簡略名を再マップの方法の 1 つを使用して、reMap最適化されたメッセージ クラスに、コントラクトを適用する関数。The following code sample demonstrates one possible way of remapping shortened names to longer ones, by defining a message contract (mapping), and using the reMap function to apply the contract to the optimized message class:

クライアント側の JavaScript コードを再配置するには、人間が判読できる名前のプロパティ名を短縮します。Client-side JavaScript code that remaps shortened property names to human-readable names

function reMap(smallObject, contract) {
    var largeObject = {};
    for (var smallProperty in contract) {
        largeObject[contract[smallProperty]] = smallObject[smallProperty];
    }
    return largeObject;
}
var shapeModelContract = {
    l: "left",
    t: "top"
};
myHub.client.setShape = function (shapeModelSmall) {
    var shapeModel = reMap(shapeModelSmall, shapeModelContract);
    // shapeModelSmall has "l" and "t" properties  but after remapping
    // shapeModel now has "left" and "top" properties
};

名前は、同じメソッドを使用しても、サーバーに、クライアントからのメッセージで短縮できます。Names can be shortened in messages from the client to the server as well, using the same method.

(つまり、メッセージに使用されるメモリ量) のメモリ使用量の削減、メッセージのオブジェクトもパフォーマンスが向上します。Reducing the memory footprint (that is, the amount of memory used for the message) of the message object can also improve performance. たとえば場合は、さまざまな、intは必要ありません、shortまたはbyte代わりに使用できます。For example, if the full range of an int is not needed, a short or byte can be used instead.

メッセージがメッセージのサイズを減らし、サーバーのメモリにメッセージ バス内で格納されるためは、サーバー メモリの問題を解決でこともできます。Since messages are stored in the message bus in server memory, reducing the size of messages can also address server memory issues.

SignalR サーバーのパフォーマンスのチューニングTuning your SignalR server for performance

SignalR アプリケーションでパフォーマンスの向上のため、サーバーをチューニングするは、次の構成設定を使用できます。The following configuration settings can be used to tune your server for better performance in a SignalR application. ASP.NET アプリケーションのパフォーマンスを向上させる方法の概要については、次を参照してください。 ASP.NET パフォーマンスの向上します。For general information on how to improve performance in an ASP.NET application, see Improving ASP.NET Performance.

SignalR の構成設定SignalR configuration settings

  • DefaultMessageBufferSize:既定では、SignalR は 1000 メッセージごとの接続のハブあたりのメモリに保持されます。DefaultMessageBufferSize: By default, SignalR retains 1000 messages in memory per hub per connection. サイズの大きいメッセージを使用している場合は、この値を減らすことで緩和できるメモリの問題を作成この可能性があります。If large messages are being used, this may create memory issues which can be alleviated by reducing this value. この設定を設定することができます、Application_Startまたは ASP.NET アプリケーションでのイベント ハンドラー、Configurationで自己ホスト型アプリケーションの OWIN startup クラスのメソッド。This setting can be set in the Application_Start event handler in an ASP.NET application, or in the Configuration method of an OWIN startup class in a self-hosted application. 次の例では、サーバーのメモリ使用量を削減するために、アプリケーションのメモリ使用量を減らすためにこの値を小さく方法を示しています。The following sample demonstrates how to reduce this value in order to reduce the memory footprint of your application in order to reduce the amount of server memory used:

    既定のメッセージ バッファーのサイズを減らすため、Startup.cs で .NET サーバー コード.NET server code in Startup.cs for decreasing default message buffer size

    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            // Any connection or hub wire up and configuration should go here
            GlobalHost.Configuration.DefaultMessageBufferSize = 500;
            app.MapSignalR();
        }
    }
    

IIS の構成設定IIS configuration settings

  • アプリケーションごとの最大同時要求:IIS の同時実行の数を増やす要求の要求の処理の使用可能なサーバー リソースが増加します。Max concurrent requests per application: Increasing the number of concurrent IIS requests will increase server resources available for serving requests. 既定値は 5000 です。この設定を向上させるのに管理者特権でコマンド プロンプトで、次のコマンドを実行します。The default value is 5000; to increase this setting, execute the following commands in an elevated command prompt:

    cd %windir%\System32\inetsrv\
    appcmd.exe set config /section:system.webserver/serverRuntime 
            /appConcurrentRequestLimit:10000
    
  • ApplicationPool QueueLength:これは、Http.sys がアプリケーション プールのキューを要求の最大数です。ApplicationPool QueueLength: This is the maximum number of requests that Http.sys queues for the application pool. キューには、新しい要求は 503「サービスを利用できません」の応答を受信します。When the queue is full, new requests receive a 503 "Service Unavailable" response. 既定値は 1000 です。The default value is 1000.

    アプリケーションをホストしているアプリケーション プールでワーカー プロセスのキューの長さを短くと、メモリ リソースを節約します。Shortening the queue length for the worker process in the application pool hosting your application will conserve memory resources. 詳細については、次を参照してください。管理、調整、およびアプリケーション プールの構成します。For more information, see Managing, Tuning, and Configuring Application Pools.

ASP.NET 構成の設定ASP.NET configuration settings

このセクションにはで設定できる構成設定が含まれています、aspnet.configファイル。This section includes configuration settings that can be set in the aspnet.config file. このファイルはプラットフォームに応じて、2 つの場所のいずれかであります。This file is found in one of two locations, depending on platform:

  • %windir%\Microsoft.NET\Framework\v4.0.30319\aspnet.config
  • %windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet.config

SignalR パフォーマンスを向上させることがあります ASP.NET の設定を以下に示します。ASP.NET settings that may improve SignalR performance include the following:

  • CPU ごとの同時要求の最大:この設定を増やすとパフォーマンスのボトルネックを軽減することがあります。Maximum concurrent requests per CPU: Increasing this setting may alleviate performance bottlenecks. この設定を大きくには、次の構成設定を追加、aspnet.configファイル。To increase this setting, add the following configuration setting to the aspnet.config file:

    <?xml version="1.0" encoding="UTF-8" ?>
    <configuration>
        <system.web>
            <applicationPool maxConcurrentRequestsPerCPU="20000" />
        </system.web>
    </configuration>
    
  • 要求キューの制限:接続の合計数を超える場合、maxConcurrentRequestsPerCPU設定すると、ASP.NET は開始キューを使用して要求を調整します。Request Queue Limit: When the total number of connections exceeds the maxConcurrentRequestsPerCPU setting, ASP.NET will start throttling requests using a queue. キューのサイズを増やすを増やすことができます、requestQueueLimit設定します。To increase the size of the queue, you can increase the requestQueueLimit setting. これを行うには、次の構成設定を追加、processModelノードconfig/machine.config(なくaspnet.config)。To do this, add the following configuration setting to the processModel node in config/machine.config (rather than aspnet.config):

    <processModel autoConfig="false" requestQueueLimit="250000" />
    

パフォーマンスの問題のトラブルシューティングTroubleshooting performance issues

このセクションでは、アプリケーションのパフォーマンスのボトルネックを見つける方法について説明します。This section describes ways to find performance bottlenecks in your application.

WebSocket が使用されていることを確認します。Verifying that WebSocket is being used

SignalR は、さまざまなトランスポートを使用して、クライアントとサーバー間の通信、WebSocket は、パフォーマンスに大きなメリットが提供し、クライアントとサーバーがサポートしている場合に使用する必要があります。While SignalR can use a variety of transports for communication between client and server, WebSocket offers a significant performance advantage, and should be used if the client and server support it. 調べるには、クライアントとサーバーが WebSocket の要件を満たしているかどうかは、次を参照してください。トランスポートとフォールバックします。To determine if your client and server meet the requirements for WebSocket, see Transports and Fallbacks. どのようなトランスポートは、アプリケーションで使用されているを確認するのには、ブラウザー開発者ツールを使用し、トランスポートが接続に使用されているログを調べてできます。To determine what transport is being used in your application, you can use the browser developer tools, and examine the logs to see what transport is being used for the connection. Internet Explorer と Chrome ブラウザーの開発ツールを使用する方法の詳細については、次を参照してください。トランスポートとフォールバックします。For information on using the browser development tools in Internet Explorer and Chrome, see Transports and Fallbacks.

SignalR パフォーマンス カウンターの使用Using SignalR performance counters

有効にして、SignalR パフォーマンス カウンターを使用する方法を説明にある、Microsoft.AspNet.SignalR.Utilsパッケージ。This section describes how to enable and use SignalR performance counters, found in the Microsoft.AspNet.SignalR.Utils package.

Signalr.exe をインストールします。Installing signalr.exe

SignalR.exe というユーティリティを使用してサーバーには、パフォーマンス カウンターを追加できます。Performance counters can be added to the server using a utility called SignalR.exe. このユーティリティをインストールするには、次の手順を実行します。To install this utility, follow these steps:

  1. Visual Studio で、次のように選択しますツール > NuGet パッケージ マネージャー > ソリューションの NuGet パッケージの管理。In Visual Studio, select Tools > NuGet Package Manager > Manage NuGet Packages for Solution

  2. 検索signalr.utilsインストールを選択します。Search for signalr.utils, and select Install.

  3. パッケージをインストールするライセンス条項に同意します。Accept the license agreement to install the package.

  4. SignalR.exe にインストールされる<project folder>/packages/Microsoft.AspNet.SignalR.Utils.<version>/toolsします。SignalR.exe will be installed to <project folder>/packages/Microsoft.AspNet.SignalR.Utils.<version>/tools.

SignalR.exe でパフォーマンス カウンターをインストールします。Installing performance counters with SignalR.exe

SignalR パフォーマンス カウンターをインストールするには、次のパラメーターを使用して、管理者特権でコマンド プロンプトで SignalR.exe を実行します。To install SignalR performance counters, run SignalR.exe in an elevated command prompt with the following parameter:

SignalR.exe ipc

SignalR パフォーマンス カウンターを削除するには、次のパラメーターを使用して、管理者特権でコマンド プロンプトで SignalR.exe を実行します。To remove SignalR performance counters, run SignalR.exe in an elevated command prompt with the following parameter:

SignalR.exe upc

SignalR パフォーマンス カウンターSignalR Performance counters

ユーティリティ パッケージは、次のパフォーマンス カウンターをインストールします。The utilities package installs the following performance counters. "Total"カウンターは、最後のアプリケーション プールまたはサーバーを再起動するために、イベントの数を計測します。The "Total" counters measure the number of events since the last application pool or server restart.

接続メトリックConnection metrics

次のメトリックは、発生する接続の有効期間イベントを測定します。The following metrics measure the connection lifetime events that occur. 詳細については、次を参照してください。接続の有効期間イベントの処理と理解します。For more information, see Understanding and Handling Connection Lifetime Events.

  • 接続されている接続Connections Connected
  • 接続の再接続Connections Reconnected
  • 接続の切断Connections Disconnected
  • 現在の接続Connections Current

メッセージ メトリックスMessage metrics

次のメトリックは、SignalR によって生成されるメッセージ トラフィックを測定します。The following metrics measure the message traffic generated by SignalR.

  • 接続メッセージの受信した合計Connection Messages Received Total
  • 合計送信接続メッセージConnection Messages Sent Total
  • 接続を受信メッセージ数/秒Connection Messages Received/Sec
  • 接続が送信メッセージ/秒Connection Messages Sent/Sec

メッセージ バスのメトリックMessage bus metrics

次のメトリックは、内部の SignalR メッセージ バス、すべての受信および送信の SignalR メッセージの配置のキューを通過するトラフィックを測定します。The following metrics measure traffic through the internal SignalR message bus, the queue in which all incoming and outgoing SignalR messages are placed. メッセージがPublishedが送信またはブロードキャストします。A message is Published when it is sent or broadcast. Aサブスクライバーメッセージ バス上のサブスクリプションは、このコンテキストでは、クライアントとサーバー自体の数と等しくなります。A Subscriber in this context is a subscription on the message bus; this should equal the number of clients plus the server itself. 割り当てられたワーカー ; のアクティブな接続にデータを送信するコンポーネントをビジー状態の Workerがアクティブにメッセージを送信する 1 つです。An Allocated Worker is a component that sends data to active connections; a Busy Worker is one that is actively sending a message.

  • メッセージ バス メッセージの受信の合計数Message Bus Messages Received Total
  • メッセージ バス メッセージの受信/秒Message Bus Messages Received/Sec
  • メッセージ バスのメッセージの合計を発行します。Message Bus Messages Published Total
  • メッセージ バス メッセージの 1 秒あたりの発行Message Bus Messages Published/Sec
  • メッセージ バスのサブスクライバーの現在Message Bus Subscribers Current
  • メッセージ バスのサブスクライバーの合計Message Bus Subscribers Total
  • メッセージ バスのサブスクライバー/秒Message Bus Subscribers/Sec
  • メッセージ バスには、ワーカーが割り当てられています。Message Bus Allocated Workers
  • メッセージ バスのビジー状態のワーカーMessage Bus Busy Workers
  • メッセージ バスのトピックの現在Message Bus Topics Current

誤差のメトリックError metrics

次のメトリックは、SignalR メッセージ トラフィックによって生成されたエラーを測定します。The following metrics measure errors generated by SignalR message traffic. ハブの解決ハブまたはハブのメソッドは解決できない場合にエラーが発生します。Hub Resolution errors occur when a hub or hub method cannot be resolved. ハブ呼び出しエラーは、ハブ メソッドの呼び出し中にスローされる例外。Hub Invocation errors are exceptions thrown while invoking a hub method. トランスポートエラーは、接続エラーの HTTP 要求または応答時にスローされます。Transport errors are connection errors thrown during an HTTP request or response.

  • エラー:すべての合計Errors: All Total
  • エラー:1 秒あたりのすべてErrors: All/Sec
  • エラー:ハブの解像度の合計Errors: Hub Resolution Total
  • エラー:ハブの解像度/秒Errors: Hub Resolution/Sec
  • エラー:ハブ呼び出し合計Errors: Hub Invocation Total
  • エラー:ハブ呼び出し数/秒Errors: Hub Invocation/Sec
  • エラー:トランスポートの合計Errors: Transport Total
  • エラー:1 秒あたりのトランスポートErrors: Transport/Sec

スケール アウトのメトリックScaleout metrics

次のメトリックは、トラフィックと、スケール アウト プロバイダーによって生成されたエラーを測定します。The following metrics measure traffic and errors generated by the scaleout provider. A Streamこのコンテキストでは、スケール ユニットはスケール アウト プロバイダーで使用される。 これは SQL Server を使用する場合は、テーブル、Service Bus を使用する場合は、トピックとサブスクリプション Redis を使用する場合。A Stream in this context is a scale unit used by the scaleout provider; this is a table if SQL Server is used, a Topic if Service Bus is used, and a Subscription if Redis is used. 各ストリームによって順序付けられた読み取りおよび書き込み操作です。1 つのストリームは、潜在的なスケール ボトルネックは、そのボトルネックを減らすためにストリームの数を増やすことができます。Each stream ensures ordered read and write operations; a single stream is a potential scale bottleneck, so the number of streams can be increased to help reduce that bottleneck. 複数のストリームを使用している場合 SignalR は自動的に配布されている順序で特定の接続から送信されたメッセージを保証する方法でこれらのストリーム間でメッセージの (数シャード) を使用します。If multiple streams are used, SignalR will automatically distribute (shard) messages across these streams in a way that ensures messages sent from any given connection are in order.

MaxQueueLength設定では、SignalR で保持されているスケール アウト送信キューの長さを制御します。The MaxQueueLength setting controls the length of the scaleout send queue maintained by SignalR. 値に設定する、構成済みのメッセージング バック プレーンに一度に 1 つずつ送信する送信キューのすべてのメッセージを配置は 0 より大きい。Setting it to a value greater than 0 will place all messages in a send queue to be sent one at a time to the configured messaging backplane. キューのサイズが構成されている長さを超えた場合では送信する後続の呼び出しがすぐに失敗、 InvalidOperationExceptionまでキュー内のメッセージの数が少ない設定よりももう一度です。If the size of the queue goes above the configured length, subsequent calls to send will fail immediately with an InvalidOperationException until the number of messages in the queue is less than the setting again. 実装されているバック プレーン一般に、独自のキューまたはフロー制御インプレース、キューが既定で無効にします。Queueing is disabled by default because the implemented backplanes generally have their own queuing or flow-control in place. 場合は、SQL Server は任意の時点で起こっているの送信メッセージの数の制限接続プールを効果的に。In the case of SQL Server, connection pooling effectively limits the number of sends going on at any one time.

SQL Server と Redis の既定では、1 つのみのストリームが使用される、Service bus の 5 つのストリームが使用される、キューが無効になっているおよびが SQL サーバーと Service Bus の構成でこれらの設定を変更できます。By default, only one stream is used for SQL Server and Redis, five streams are used for Service Bus, and queueing is disabled, but these settings can be changed through configuration on SQL Server and Service Bus:

SQL Server のバック プレーンのテーブルの数とキューの長さを構成するための .NET サーバー コード.NET Server Code for configuring table count and queue length for SQL Server backplane

var connectionString = "(your connection string)";
var config = new SqlScaleoutConfiguration(connectionString) { 
TableCount = 3,
MaxQueueLength = 50 };
GlobalHost.DependencyResolver.UseSqlServer(config);

バック プレーンの Service Bus のトピックの数とキューの長さを構成するための .NET サーバー コード.NET Server Code for configuring topic count and queue length for Service Bus backplane

string connectionString = "(your connection string)";
var config = new ServiceBusScaleoutConfiguration(connectionString, "YourAppName") { 
TopicCount = 3,
MaxQueueLength = 50 };
GlobalHost.DependencyResolver.UseServiceBus(config);

Aバッファリングストリームが途中終了状態に入った 1 つ。 ストリームが不要になったエラーになるまでにすぐにバック プレーンに送信されるすべてのメッセージはエラー ストリームが途中終了状態のときは、にします。A Buffering stream is one that has entered a faulted state; when the stream is in the faulted state, all messages sent to the backplane will fail immediately until the stream is no longer faulting. Send Queue Lengthは送信されているが、まだ送信されるメッセージの数です。The Send Queue Length is the number of messages that have been posted but not yet sent.

  • スケール アウト メッセージ バス メッセージの受信/秒Scaleout Message Bus Messages Received/Sec
  • スケール アウトのストリームの合計Scaleout Streams Total
  • スケール アウトのストリームを開くScaleout Streams Open
  • スケール アウト ストリームのバッファリングScaleout Streams Buffering
  • スケール アウト エラーの合計Scaleout Errors Total
  • スケール アウト エラー/秒Scaleout Errors/Sec
  • スケール アウト送信キューの長さScaleout Send Queue Length

これらのカウンターの測定の詳細については、次を参照してください。 Azure Service Bus による SignalR スケール アウトします。For more information on what these counters are measuring, see SignalR Scaleout with Azure Service Bus.

その他のパフォーマンス カウンターの使用Using other performance counters

次のパフォーマンス カウンターも、アプリケーションのパフォーマンスの監視に役立つ場合があります。The following performance counters may also be useful in monitoring your application's performance.

メモリMemory

  • .NET CLR Memory\ヒープ (w3wp) をすべて # bytes.NET CLR Memory\# bytes in all Heaps (for w3wp)

ASP.NETASP.NET

  • ASP.NET\Requests CurrentASP.NET\Requests Current
  • ASP.NET\QueuedASP.NET\Queued
  • ASP.NET\RejectedASP.NET\Rejected

CPUCPU

  • プロセッサ時間の Information\ProcessorProcessor Information\Processor Time

TCP/IPTCP/IP

  • TCPv6/接続の確立TCPv6/Connections Established
  • TCPv4/接続の確立TCPv4/Connections Established

Web サービスWeb Service

  • Web service \current ConnectionsWeb Service\Current Connections
  • Web Service\Maximum 接続Web Service\Maximum Connections

スレッド化Threading

  • .NET CLR をロックおよびスレッド\現在の論理スレッド数.NET CLR Locks And Threads\# of current logical Threads
  • .NET CLR をロックおよびスレッド\物理的な現在のスレッドの数.NET CLR Locks And Threads\# of current physical Threads

その他の参照情報Other Resources

ASP.NET パフォーマンスの監視とチューニングの詳細については、次のトピックを参照してください。For more information on ASP.NET performance monitoring and tuning, see the following topics: