SignalR-Leistung (SignalR 1.x)

  • Artikel

von Patrick Fletcher

Warnung

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

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

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 das Generieren von unnötigem Netzwerkdatenverkehr beeinträchtigt wird.

Häufigkeit von Drosselungsmeldungen

Selbst in einer Anwendung, die Nachrichten mit hoher Häufigkeit sendet (z. B. eine Echtzeit-Gaming-Anwendung), müssen die meisten Anwendungen nicht mehr als ein paar Nachrichten pro Sekunde senden. Um den Datenverkehr zu reduzieren, den jeder Client generiert, kann eine Nachrichtenschleife implementiert werden, die Nachrichten nicht häufiger als eine feste Rate in warteschlangen und sendet (das heißt, bis zu einer bestimmten Anzahl von Nachrichten wird jede Sekunde gesendet, wenn nachrichten in diesem Zeitintervall gesendet werden sollen). 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 reduzieren, indem Sie die Größe Ihrer serialisierten Objekte reduzieren. 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 Reduzieren 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/Wartbarkeit im Clientcode zu erhalten, können die abgekürzten Eigenschaftsnamen nach Dem Empfang der Nachricht den Namen der Benutzerfreundlichkeit neu zugeordnet werden. Im folgenden Codebeispiel wird eine mögliche Möglichkeit veranschaulicht, verkürzte Namen in längere namen 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 lesbaren Namen zuordnet

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 Arbeitsspeicherbedarfs (d. h. der Für die Nachricht verwendete Arbeitsspeicher) 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 die Verringerung der Größe von Nachrichten auch Probleme mit dem Serverspeicher beheben.

Optimieren des SignalR-Servers auf 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: SignalR behält standardmäßig 1.000 Nachrichten pro Hub und Verbindung im Arbeitsspeicher. Wenn große Nachrichten verwendet werden, kann dies zu Speicherproblemen führen, die durch Reduzieren dieses Werts gelindert 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 reduzieren, um den Arbeitsspeicherbedarf Ihrer Anwendung zu reduzieren, um die Menge des verwendeten Serverspeichers zu verringern:

    .NET-Servercode in Global.asax zum Verringern der Standardgröße des Nachrichtenpuffers

    protected void Application_Start(object sender, EventArgs e)
{
    GlobalHost.Configuration.DefaultMessageBufferSize = 500;
}

IIS-Konfigurationseinstellungen

  • Maximale Anzahl gleichzeitiger Anforderungen pro Anwendung: Durch das Erhöhen der Anzahl gleichzeitiger IIS-Anforderungen werden serverressourcen erhöht, die für die Bereitstellung von Anforderungen verfügbar sind. Der Standardwert ist 5000; Führen Sie die folgenden Befehle an einer Eingabeaufforderung mit erhöhten Rechten aus, um diese Einstellung zu erhöhen:

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

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 gleichzeitiger 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 Einschränkung 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 dem Knoten in config/machine.config (statt aspnet.config) die processModel folgende Konfigurationseinstellung hinzu:

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

Problembehandlung bei Leistungsproblemen

In diesem Abschnitt wird beschrieben, wie Sie Leistungsengpässe in Ihrer Anwendung finden können.

Überprüfen der Verwendung von WebSocket

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 Sie SignalR-Leistungsindikatoren im Microsoft.AspNet.SignalR.Utils Paket aktivieren und verwenden.

Installieren von signalr.exe

Leistungsindikatoren können dem Server mithilfe eines Hilfsprogramms namens SignalR.exe hinzugefügt werden. Führen Sie zum Installieren dieses Hilfsprogramms die folgenden Schritte aus:

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

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

    Screenshot: Microsoft A S P dot NET Signal R Utilities Befehlszeilenhilfsprogramme für A S P dot NET Signal R hervorgehoben.

  3. Akzeptieren Sie die Lizenzvereinbarung, 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 in einer Eingabeaufforderung mit erhöhten Rechten mit dem folgenden Parameter aus:

SignalR.exe ipc

Um SignalR-Leistungsindikatoren zu entfernen, führen Sie SignalR.exe in 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 der Verbindungslebensdauer, die auftreten. Weitere Informationen finden Sie unter Grundlegendes und Behandeln von Verbindungslebensdauerereignissen.

  • Verbundene Verbindungen
  • Verbindungen wieder verbunden
  • Verbindungen getrennt
  • Aktuelle Verbindungen

Nachrichtenmetriken

Die folgenden Metriken messen den von SignalR generierten Nachrichtendatenverkehr.

  • Gesamtsumme empfangener Verbindungsnachrichten
  • Gesendete Verbindungsnachrichten insgesamt
  • Empfangene Verbindungsmeldungen/Sek.
  • Gesendete Verbindungsmeldungen/Sek.

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 gesendet wird. Ein Abonnent in diesem Kontext ist ein Abonnement auf dem 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 Busy Worker ist ein Mitarbeiter, der aktiv eine Nachricht sendet.

  • Nachrichtenbusnachrichten insgesamt empfangen
  • Empfangene Nachrichten bus-Nachrichten/Sek.
  • Veröffentlichte Nachrichtenbusnachrichten insgesamt
  • Veröffentlichte Nachrichten bus-Nachrichten/Sek.
  • Nachrichtenbusabonnenten aktuell
  • Message Bus-Abonnenten insgesamt
  • Message Bus-Abonnenten/Sek.
  • Nachrichtenbus zugeordnete Worker
  • Message Bus Busy Worker
  • Nachrichtenbusthemen aktuell

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. Hubaufruffehler 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: Gesamt
  • Fehler: Alle/Sek.
  • Fehler: Hubauflösung gesamt
  • Fehler: Hubauflösung/Sek.
  • Fehler: Hubaufruf gesamt
  • Fehler: Hubaufruf/Sek.
  • Fehler: Transportsumme
  • Fehler: Transport/Sek.

Skalierungsmetriken

Mit den folgenden Metriken werden Datenverkehr und Fehler gemessen, die vom Scaleout-Anbieter 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. Standardmäßig wird nur ein Stream verwendet, der jedoch durch die Konfiguration auf SQL Server und Service Bus erhöht werden kann. Ein Pufferdatenstrom ist in einen fehlerhaften Zustand eingetreten. wenn sich der Stream im fehlerhaften Zustand befindet, schlagen alle Nachrichten, die an die Backplane gesendet werden, sofort fehl, bis der Stream keine Fehler mehr aufweist. Die Länge der Sendewarteschlange ist die Anzahl der Nachrichten, die gepostet, aber noch nicht gesendet wurden.

  • Scaleout Message Bus-Nachrichten empfangen/Sek.
  • Skalierung von Streams insgesamt
  • Horizontale Datenströme geöffnet
  • Pufferung von Skalierungsdatenströmen
  • Horizontale Skalierungsfehler gesamt
  • Skalierungsfehler/Sek.
  • 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\Aktuelle Anforderungen
  • ASP.NET\Queued
  • ASP.NET\Abgelehnt

CPU

  • Prozessorinformationen\Prozessorzeit

TCP/IP

  • TCPv6/Verbindungen eingerichtet
  • TCPv4/Verbindungen hergestellt

Webdienst

  • Webdienst\Aktuelle Verbindungen
  • Webdienst\Maximale Verbindungen

Threading

  • .NET CLR LocksAndThreads# der aktuellen logischen Threads
  • .NET CLR LocksAnd Threads# der aktuellen physischen Threads

Weitere Ressourcen

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