Testen der Verbindungsdichte in SignalR mit Crank

  • Artikel

von Tom FitzMacken

Warnung

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

In diesem Artikel wird beschrieben, wie Sie das Crank-Tool verwenden, um eine Anwendung mit mehreren simulierten Clients zu testen.

Sobald Ihre Anwendung in ihrer Hostingumgebung ausgeführt wird (entweder eine Azure-Webrolle, IIS oder selbstgehostet mit Owin), können Sie die Antwort der Anwendung auf eine hohe Verbindungsdichte mit dem Tool Crank testen. Die Hostingumgebung kann ein IIS-Server (Internetinformationsdienste), ein Owin-Host oder eine Azure-Webrolle sein. (Hinweis: Leistungsindikatoren sind auf Azure App Service Web-Apps nicht verfügbar, sodass Sie keine Leistungsdaten aus einem Verbindungsdichtetest abrufen können.)

Verbindungsdichte bezieht sich auf die Anzahl gleichzeitiger TCP-Verbindungen, die auf einem Server hergestellt werden können. Jede TCP-Verbindung verursacht einen eigenen Mehraufwand, und das Öffnen einer großen Anzahl von Verbindungen im Leerlauf führt schließlich zu einem Speicherengpass.

Die SignalR-Codebasis enthält ein Auslastungstesttool namens Crank. Die neueste Version von Crank finden Sie im Dev-Branch auf GitHub. Sie können hier ein Zip-Archiv des Dev-Branchs der SignalR-Codebasis herunterladen.

Crank kann verwendet werden, um den Arbeitsspeicher des Servers vollständig zu überlasten, um die Gesamtzahl der auf der Serverhardware möglichen Verbindungen im Leerlauf zu berechnen. Alternativ können Sie auch Crank verwenden, um den Server unter einer bestimmten Arbeitsspeicherauslastung zu testen, indem Sie Verbindungen hochfahren, bis eine bestimmte Anzahl oder ein bestimmter Arbeitsspeicherschwellenwert erreicht ist.

Beim Testen ist es wichtig, Remoteclients zu verwenden, um jegliche Konkurrenz um Ressourcen (d. h. TCP-Verbindungen und Arbeitsspeicher) zu vermeiden. Überwachen Sie die Clients, um sicherzustellen, dass keine Engpässe auftreten, die den Server daran hindern können, seine volle Kapazität (Arbeitsspeicher oder CPU) zu erreichen. Möglicherweise müssen Sie die Anzahl der Clients erhöhen, um den Server vollständig zu laden.

Ausführen eines Verbindungsdichtetests

In diesem Abschnitt werden die Schritte beschrieben, die zum Ausführen eines Verbindungsdichtetests für eine SignalR-Anwendung erforderlich sind.

  1. Laden Sie den Dev-Branch der SignalR-Codebasis herunter, und erstellen Sie sie. Navigieren Sie an einer Eingabeaufforderung zu <project directory>\src\Microsoft.AspNet.SignalR.Crank\bin\debug.
  2. Stellen Sie Ihre Anwendung in der vorgesehenen Hostingumgebung bereit. Notieren Sie sich den Endpunkt, den Ihre Anwendung verwendet. In der anwendung, die im tutorial Erste Schritte erstellt wurde, ist http://<yourhost>:8080/signalrder Endpunkt beispielsweise .
  3. Installieren Sie SignalR-Leistungsindikatoren auf dem Server. Wenn Ihre Anwendung in Azure ausgeführt wird, finden Sie weitere Informationen unter Verwenden von SignalR-Leistungsindikatoren in einer Azure-Webrolle.

Nachdem Sie die Codebasis heruntergeladen und erstellt und Leistungsindikatoren auf Ihrem Host installiert haben, befindet sich das Befehlszeilentool Crank im src\Microsoft.AspNet.SignalR.Crank\bin\Debug Ordner.

Zu den verfügbaren Optionen für das Crank-Tool gehören:

  • /?: Zeigt den Hilfebildschirm an. Die verfügbaren Optionen werden auch angezeigt, wenn der Url-Parameter ausgelassen wird.
  • /Url: Die URL für SignalR-Verbindungen. Dieser Parameter ist erforderlich. Bei einer SignalR-Anwendung, die die Standardzuordnung verwendet, endet der Pfad auf "/signalr".
  • /Transport: Der Name des verwendeten Transports. Der Standardwert ist auto, wodurch das beste verfügbare Protokoll ausgewählt wird. Zu den Optionen gehören WebSockets, ServerSentEventsund LongPolling (ForeverFrame ist keine Option für Crank, da der .NET-Client anstelle von Internet Explorer verwendet wird). Weitere Informationen dazu, wie SignalR Transporte auswählt, finden Sie unter Transporte und Fallbacks.
  • /BatchSize: Die Anzahl der Clients, die in jedem Batch hinzugefügt wurden. Der Standardwert ist 50.
  • /ConnectInterval: Das Intervall in Millisekunden zwischen dem Hinzufügen von Verbindungen. Der Standard ist 500.
  • /Connections: Die Anzahl der Verbindungen, die zum Auslastungstest der Anwendung verwendet werden. Der Standardwert ist 100.000.
  • /ConnectTimeout: Das Timeout in Sekunden, bevor der Test abgebrochen wird. Der Standardwert ist 300.
  • MinServerMBytes: Die zu erreichende Mindestanzahl von Server-Megabytes. Der Standard ist 500.
  • SendBytes: Die Größe der an den Server gesendeten Nutzlast in Bytes. Die Standardeinstellung ist 0.
  • SendInterval: Die Verzögerung in Millisekunden zwischen Nachrichten an den Server. Der Standard ist 500.
  • SendTimeout: Das Timeout in Millisekunden für Nachrichten an den Server. Der Standardwert ist 300.
  • ControllerUrl: Die URL, in der ein Client einen Controllerhub hosten wird. Der Standardwert ist NULL (kein Controllerhub). Der Controllerhub wird gestartet, wenn die Crank-Sitzung gestartet wird. Es wird kein weiterer Kontakt zwischen controller hub und Crank hergestellt.
  • NumClients: Die Anzahl der simulierten Clients, die eine Verbindung mit der Anwendung herstellen sollen. Der Standardwert ist 1.
  • Logfile: Der Dateiname für die Protokolldatei für die Testausführung. Der Standardwert ist crank.csv.
  • SampleInterval: Die Zeit in Millisekunden zwischen Leistungsindikatorbeispielen. Der Standardwert lautet 1000.
  • SignalRInstance: Der instance Name für die Leistungsindikatoren auf dem Server. Standardmäßig wird der Clientverbindungsstatus verwendet.

Beispiel

Der folgende Befehl testet einen Standort namens pfsignalr in Azure, der eine Anwendung an Port 8080 mit einem Hub namens "ControllerHub" hostet, wobei 100 Verbindungen verwendet werden.

crank /Connections:100 /Url:http://pfsignalr.cloudapp.net:8080/signalr