Freigeben über

SignalR-Leistung

  • Artikel

von Patrick Fletcher

Warnung

Diese Dokumentation ist nicht für die neueste Version von SignalR vorgesehen. Sehen Sie sich ASP.NET Core SignalR an.

In diesem Thema wird beschrieben, wie Sie die Leistung in einer SignalR-Anwendung entwerfen, messen und verbessern.

In diesem Thema verwendete Softwareversionen

Frühere Versionen dieses Themas

Informationen zu früheren Versionen von SignalR finden Sie unter Ältere Versionen von SignalR.

Fragen und Kommentare

Bitte hinterlassen Sie Feedback darüber, wie Ihnen dieses Tutorial gefallen hat und was wir in den Kommentaren unten auf der Seite verbessern könnten. Wenn Sie Fragen haben, die sich nicht direkt auf das Tutorial beziehen, können Sie diese im ASP.NET SignalR-Forum oder im StackOverflow.com posten.

Eine aktuelle Präsentation zur Leistung und Skalierung von SignalR finden Sie unter Skalieren des Echtzeitwebs mit ASP.NET SignalR.

Dieses Thema enthält folgende Abschnitte:

Überlegungen zum Entwurf

In diesem Abschnitt werden Muster beschrieben, die während des Entwurfs einer SignalR-Anwendung implementiert werden können, um sicherzustellen, dass die Leistung nicht durch die Generierung unnötiger Netzwerkdatenverkehr beeinträchtigt wird.

Häufigkeit von Drosselungsmeldungen

Selbst in einer Anwendung, die Nachrichten mit hoher Frequenz sendet (z. B. eine Echtzeit-Gaming-Anwendung), müssen die meisten Anwendungen nicht mehr als ein paar Nachrichten pro Sekunde senden. Um die Menge des Datenverkehrs zu reduzieren, den jeder Client generiert, kann eine Nachrichtenschleife implementiert werden, die Nachrichten nicht häufiger als eine feste Rate in die Warteschlange stellt und sendet (d. a. bis zu einer bestimmten Anzahl von Nachrichten wird jede Sekunde gesendet, wenn Nachrichten in diesem Zeitintervall gesendet werden). Eine Beispielanwendung, die Nachrichten auf eine bestimmte Rate (sowohl vom Client als auch vom Server) drosselt, finden Sie unter Hochfrequenz-Echtzeit mit SignalR.

Reduzieren der Nachrichtengröße

Sie können die Größe einer SignalR-Nachricht verringern, indem Sie die Größe Ihrer serialisierten Objekte verringern. Wenn Sie im Servercode ein Objekt senden, das Eigenschaften enthält, die nicht übertragen werden müssen, verhindern Sie, dass diese Eigenschaften mithilfe des JsonIgnore -Attributs serialisiert werden. Die Namen der Eigenschaften werden auch in der Nachricht gespeichert. die Namen von Eigenschaften können mithilfe des JsonProperty -Attributs gekürzt werden. Im folgenden Codebeispiel wird veranschaulicht, wie eine Eigenschaft vom Senden an den Client ausgeschlossen wird und wie Eigenschaftennamen gekürzt werden:

.NET-Servercode, der das JsonIgnore-Attribut zum Ausschließen von Daten vom Senden an den Client und das JsonProperty-Attribut zum Verringern der Nachrichtengröße veranschaulicht

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; }
}

Um die Lesbarkeit/Verwaltbarkeit im Clientcode zu erhalten, können die abgekürzten Eigenschaftsnamen nach dem Empfang der Nachricht den Anzeigenamen erneut zugeordnet werden. Im folgenden Codebeispiel wird eine mögliche Möglichkeit veranschaulicht, verkürzte Namen in längere Zunge umzugestalten, indem ein Nachrichtenvertrag (Zuordnung) definiert und die reMap -Funktion verwendet wird, um den Vertrag auf die optimierte Nachrichtenklasse anzuwenden:

Clientseitiger JavaScript-Code, der verkürzte Eigenschaftsnamen zu für Menschen lesbaren Namen neu ordnet

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
};

Namen können auch in Nachrichten vom Client an den Server mit der gleichen Methode gekürzt werden.

Das Reduzieren des Speicherbedarfs (d. h. die Menge des für die Nachricht verwendeten Arbeitsspeichers) des Nachrichtenobjekts kann auch die Leistung verbessern. Wenn beispielsweise der gesamte Bereich eines int nicht benötigt wird, kann stattdessen ein short oder byte verwendet werden.

Da Nachrichten im Nachrichtenbus im Serverspeicher gespeichert werden, kann das Reduzieren der Größe von Nachrichten auch Serverspeicherprobleme beheben.

Optimieren des SignalR-Servers für die Leistung

Die folgenden Konfigurationseinstellungen können verwendet werden, um Ihren Server für eine bessere Leistung in einer SignalR-Anwendung zu optimieren. Allgemeine Informationen zum Verbessern der Leistung in einer ASP.NET-Anwendung finden Sie unter Verbessern ASP.NET Leistung.

SignalR-Konfigurationseinstellungen

  • DefaultMessageBufferSize: Standardmäßig behält SignalR 1000 Nachrichten im Arbeitsspeicher pro Hub und Verbindung bei. Wenn große Nachrichten verwendet werden, kann dies zu Speicherproblemen führen, die durch Verringern dieses Werts behoben werden können. Diese Einstellung kann im Application_Start Ereignishandler in einer ASP.NET-Anwendung oder in der Configuration -Methode einer OWIN-Startklasse in einer selbstgehosteten Anwendung festgelegt werden. Im folgenden Beispiel wird veranschaulicht, wie Sie diesen Wert verringern, um den Speicherbedarf Ihrer Anwendung zu verringern, um die Menge des verwendeten Serverarbeitsspeichers zu reduzieren:

    .NET-Servercode in Startup.cs zum Verringern der Standardmeldungspuffergröße

    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-Konfigurationseinstellungen

  • Maximale Anzahl gleichzeitiger Anforderungen pro Anwendung: Wenn Sie die Anzahl gleichzeitiger IIS-Anforderungen erhöhen, erhöhen sich die verfügbaren Serverressourcen für die Bereitstellung von Anforderungen. Der Standardwert ist 5000; Um diese Einstellung zu erhöhen, führen Sie die folgenden Befehle an einer Eingabeaufforderung mit erhöhten Rechten aus:

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

  • ApplicationPool QueueLength: Dies ist die maximale Anzahl von Anforderungen, die Warteschlangen für den Anwendungspool Http.sys. Wenn die Warteschlange voll ist, erhalten neue Anforderungen die Antwort 503 "Dienst nicht verfügbar". Der Standardwert lautet „1000“.

    Durch das Verkürzen der Warteschlangenlänge für den Arbeitsprozess im Anwendungspool, der Ihre Anwendung hosten, werden Speicherressourcen eingespart. Weitere Informationen finden Sie unter Verwalten, Optimieren und Konfigurieren von Anwendungspools.

ASP.NET Konfigurationseinstellungen

Dieser Abschnitt enthält Konfigurationseinstellungen, die in der aspnet.config Datei festgelegt werden können. Diese Datei befindet sich je nach Plattform an einem von zwei Speicherorten:

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

ASP.NET Einstellungen, die die SignalR-Leistung verbessern können, gehören folgendes:

  • Maximale anzahl gleichzeitige Anforderungen pro CPU: Das Erhöhen dieser Einstellung kann Leistungsengpässe verringern. Um diese Einstellung zu erhöhen, fügen Sie der Datei die aspnet.config folgende Konfigurationseinstellung hinzu:

    <?xml version="1.0" encoding="UTF-8" ?>
<configuration>
    <system.web>
        <applicationPool maxConcurrentRequestsPerCPU="20000" />
    </system.web>
</configuration>

  • Anforderungswarteschlangenlimit: Wenn die Gesamtzahl der Verbindungen die maxConcurrentRequestsPerCPU Einstellung überschreitet, beginnt ASP.NET mit der Drosselung von Anforderungen mithilfe einer Warteschlange. Um die Größe der Warteschlange zu erhöhen, können Sie die requestQueueLimit Einstellung erhöhen. Fügen Sie dazu die folgende Konfigurationseinstellung dem processModel Knoten in config/machine.config hinzu (anstelle aspnet.configvon ):

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

Problembehandlung bei Leistungsproblemen

In diesem Abschnitt werden Möglichkeiten zum Ermitteln von Leistungsengpässen in Ihrer Anwendung beschrieben.

Überprüfen, ob WebSocket verwendet wird

Während SignalR eine Vielzahl von Transporten für die Kommunikation zwischen Client und Server verwenden kann, bietet WebSocket einen erheblichen Leistungsvorteil und sollte verwendet werden, wenn client und server dies unterstützen. Informationen dazu, ob Ihr Client und Server die Anforderungen für WebSocket erfüllen, finden Sie unter Transporte und Fallbacks. Um zu bestimmen, welcher Transport in Ihrer Anwendung verwendet wird, können Sie die Browserentwicklertools verwenden und die Protokolle untersuchen, um festzustellen, welcher Transport für die Verbindung verwendet wird. Informationen zur Verwendung der Browserentwicklungstools in Internet Explorer und Chrome finden Sie unter Transporte und Fallbacks.

Verwenden von SignalR-Leistungsindikatoren

In diesem Abschnitt wird beschrieben, wie SignalR-Leistungsindikatoren im Microsoft.AspNet.SignalR.Utils Paket aktiviert und verwendet werden.

Installieren von signalr.exe

Leistungsindikatoren können dem Server mithilfe eines Hilfsprogramms namens SignalR.exe hinzugefügt werden. Führen Sie die folgenden Schritte aus, um dieses Hilfsprogramm zu installieren:

  1. Wählen Sie in Visual Studio Tools>NuGet-Paket-Manager>NuGet-Pakete für Projektmappe verwalten aus.

  2. Suchen Sie nach signalr.utils, und wählen Sie Installieren aus.

    Screenshot: Ausgewählte Microsoft A S P dot NET Signal R-Hilfsprogramme

  3. Akzeptieren Sie den Lizenzvertrag, um das Paket zu installieren.

  4. SignalR.exe wird in <project folder>/packages/Microsoft.AspNet.SignalR.Utils.<version>/toolsinstalliert.

Installieren von Leistungsindikatoren mit SignalR.exe

Um SignalR-Leistungsindikatoren zu installieren, führen Sie SignalR.exe an einer Eingabeaufforderung mit erhöhten Rechten mit dem folgenden Parameter aus:

SignalR.exe ipc

Um SignalR-Leistungsindikatoren zu entfernen, führen Sie SignalR.exe an einer Eingabeaufforderung mit erhöhten Rechten mit dem folgenden Parameter aus:

SignalR.exe upc

SignalR-Leistungsindikatoren

Das Hilfsprogrammpaket installiert die folgenden Leistungsindikatoren. Die Indikatoren "Total" messen die Anzahl der Ereignisse seit dem letzten Anwendungspool- oder Serverneustart.

Verbindungsmetriken

Die folgenden Metriken messen die Ereignisse für die Verbindungslebensdauer, die auftreten. Weitere Informationen finden Sie unter Grundlegendes und Behandeln von Verbindungslebensdauerereignissen.

  • Verbundene Verbindungen
  • Wieder hergestellte Verbindungen
  • Verbindungen getrennt
  • Aktuelle Verbindungen

Nachrichtenmetriken

Die folgenden Metriken messen den von SignalR generierten Nachrichtendatenverkehr.

  • Empfangene Verbindungsmeldungen insgesamt
  • Gesendete Verbindungsnachrichten insgesamt
  • Empfangene Verbindungsmeldungen/Sekunde
  • Gesendete Verbindungsmeldungen/Sekunde

Nachrichtenbusmetriken

Die folgenden Metriken messen den Datenverkehr über den internen SignalR-Nachrichtenbus, die Warteschlange, in der alle eingehenden und ausgehenden SignalR-Nachrichten platziert werden. Eine Nachricht wird veröffentlicht , wenn sie gesendet oder übertragen wird. Ein Abonnent in diesem Kontext ist ein Abonnement im Nachrichtenbus. dies sollte der Anzahl der Clients plus dem Server selbst entsprechen. Ein zugeordneter Worker ist eine Komponente, die Daten an aktive Verbindungen sendet. Ein beschäftigter Worker ist ein Mitarbeiter, der aktiv eine Nachricht sendet.

  • Empfangene Nachrichtenbusnachrichten insgesamt
  • Empfangene Nachrichtenbusnachrichten/Sekunde
  • Veröffentlichte Nachrichtenbusnachrichten insgesamt
  • Nachrichtenbusnachrichten veröffentlicht/Sekunde
  • Aktuelle Nachrichtenbusabonnenten
  • Nachrichtenbusabonnenten gesamt
  • Nachrichtenbusabonnenten/Sekunde
  • Zugeordnete Worker für den Nachrichtenbus
  • Ausgelastete Mitarbeiter für Nachrichtenbus
  • Aktuelle Nachrichtenbusthemen

Fehlermetriken

Die folgenden Metriken messen Fehler, die vom SignalR-Nachrichtendatenverkehr generiert werden. Hubauflösungsfehler treten auf, wenn ein Hub oder eine Hubmethode nicht aufgelöst werden kann. Hub-Aufruffehler sind Ausnahmen, die beim Aufrufen einer Hubmethode ausgelöst werden. Transportfehler sind Verbindungsfehler, die während einer HTTP-Anforderung oder -Antwort ausgelöst werden.

  • Fehler: Gesamtsumme
  • Fehler: Alle/Sekunde
  • Fehler: Hubauflösung gesamt
  • Fehler: Hubauflösung/Sekunde
  • Fehler: Hubaufruf gesamt
  • Fehler: Hubaufruf/Sekunde
  • Fehler: Transportsumme
  • Fehler: Transport/Sekunde

Scaleout-Metriken

Die folgenden Metriken messen datenverkehr und Fehler, die vom Anbieter für horizontale Skalierung generiert werden. Ein Stream ist in diesem Kontext eine Skalierungseinheit, die vom Skalierungsanbieter verwendet wird. Dies ist eine Tabelle, wenn SQL Server verwendet wird, ein Thema, wenn Service Bus verwendet wird, und ein Abonnement, wenn Redis verwendet wird. Jeder Stream stellt geordnete Lese- und Schreibvorgänge sicher. Ein einzelner Stream ist ein potenzieller Skalierungsengpass, sodass die Anzahl der Datenströme erhöht werden kann, um diesen Engpass zu verringern. Wenn mehrere Datenströme verwendet werden, verteilt SignalR automatisch Nachrichten (Shards) auf diese Streams, sodass sichergestellt wird, dass die von einer bestimmten Verbindung gesendeten Nachrichten in ordnung sind.

Die MaxQueueLength-Einstellung steuert die Länge der Sendewarteschlange für horizontales Skalieren, die von SignalR verwaltet wird. Wenn sie auf einen Wert größer als 0 festgelegt wird, werden alle Nachrichten in einer Sendewarteschlange platziert, die einzeln an die konfigurierte Messaging-Backplane gesendet werden. Wenn die Größe der Warteschlange die konfigurierte Länge überschreitet, schlagen nachfolgende zu sendende Aufrufe sofort mit einer InvalidOperationException fehl, bis die Anzahl der Nachrichten in der Warteschlange wieder kleiner als die Einstellung ist. Die Warteschlange ist standardmäßig deaktiviert, da die implementierten Backplanes in der Regel über eine eigene Warteschlangen- oder Flusssteuerung verfügen. Im Fall von SQL Server begrenzt das Verbindungspooling effektiv die Anzahl von Sendevorgängen, die zu einem beliebigen Zeitpunkt ausgeführt werden.

Standardmäßig wird nur ein Stream für SQL Server und Redis verwendet, fünf Streams werden für Service Bus verwendet, und die Warteschlange ist deaktiviert. Diese Einstellungen können jedoch über die Konfiguration für SQL Server und Service Bus geändert werden:

.NET-Servercode zum Konfigurieren der Tabellenanzahl und Warteschlangenlänge für SQL Server Backplane

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

.NET-Servercode zum Konfigurieren der Themenanzahl und Warteschlangenlänge für Service Bus-Backplane

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

Ein Pufferdatenstrom ist ein Datenstrom, der in einen fehlerhaften Zustand versetzt wurde. Wenn sich der Stream im fehlerhaften Zustand befindet, schlagen alle an die Backplane gesendeten Nachrichten sofort fehl, bis der Stream nicht mehr fehlerhaft ist. Die Länge der Sendewarteschlange gibt die Anzahl der Nachrichten an, die gepostet, aber noch nicht gesendet wurden.

  • Empfangene Nachrichtenbusnachrichten für horizontales Skalieren/Sekunde
  • Horizontale Skalierung von Datenströmen insgesamt
  • Datenströme mit horizontaler Skalierung geöffnet
  • Pufferung von Datenströmen für horizontales Hochskalieren
  • Horizontale Skalierungsfehler gesamt
  • Skalierungsfehler/Sekunde
  • Länge der Horizontalen Sendewarteschlange

Weitere Informationen dazu, was diese Indikatoren messen, finden Sie unter SignalR Scaleout mit Azure Service Bus.

Verwenden anderer Leistungsindikatoren

Die folgenden Leistungsindikatoren können auch nützlich sein, um die Leistung Ihrer Anwendung zu überwachen.

Memory

  • .NET CLR Memory\# Bytes in allen Heaps (für w3wp)

ASP.NET

  • ASP.NET\Requests Current
  • ASP.NET\In die Warteschlange eingereiht
  • ASP.NET\Abgelehnt

CPU

  • Prozessorinformationen\Prozessorzeit

TCP/IP

  • TCPv6/Hergestellte Verbindungen
  • TCPv4/Hergestellte Verbindungen

Webdienst

  • Webdienst\Aktuelle Verbindungen
  • Webdienst\Maximale Verbindungen

Threading

  • .NET CLR-Sperren und -Threads\# der aktuellen logischen Threads
  • .NET CLR-Sperren und -Threads\# von aktuellen physischen Threads

Weitere Ressourcen

Weitere Informationen zur ASP.NET Leistungsüberwachung und -optimierung finden Sie in den folgenden Themen: