Leitfaden zur Leistung für Azure SignalR Service
Einer der Hauptvorteile der Verwendung von Azure SignalR Service ist die einfache Skalierung von SignalR-Anwendungen. In einem Szenario mit großem Umfang ist die Leistung ein wichtiger Faktor.
Dieser Artikel beschreibt Folgendes:
- Die Faktoren, die sich auf die SignalR-Anwendungsleistung auswirken.
- Die typische Leistung in unterschiedlichen Anwendungsfällen.
- Die Umgebung und Tools, die Sie zum Generieren eines Leistungsberichts verwenden können.
Schnelle Auswertung mithilfe von Metriken
Sie können Ihren Dienst ganz einfach im Azure-Portal überwachen. Auf der Seite "Metriken " Ihrer SignalR-Instanz können Sie die Serverlademetriken auswählen, um den "Druck" Ihres Diensts anzuzeigen.
Das Diagramm zeigt den Rechendruck Ihres SignalR-Diensts. Sie können Ihr Szenario testen und diese Metrik überprüfen, um zu entscheiden, ob die Skalierung hochgesetzt werden soll. Die Latenz innerhalb des SignalR-Diensts ist neu Standard niedrig, wenn die Serverlast unter 70 % liegt.
Hinweis
Wenn Sie Einheit 50 oder größer verwenden und Ihr Szenario Standard kleine Gruppen (Gruppengröße <20) oder eine einzelne Verbindung sendet, müssen Sie das Senden an kleine Gruppe oder das Senden an die Verbindung überprüfen. In diesen Szenarien fallen hohe Routingkosten an, die nicht in der Serverlast enthalten sind.
Begriffsdefinitionen
Eingehend: Die eingehende Nachricht an den Azure SignalR Service.
Ausgehend: Die ausgehende Nachricht vom Azure SignalR Service.
Bandbreite: Die Gesamtgröße aller Nachrichten in einer Sekunde.
Standardmodus: Der Standardarbeitsmodus, wenn eine Azure SignalR Service-Instanz erstellt wird. Der Azure SignalR-Dienst erwartet, dass der App-Server eine Verbindung damit herstellt, bevor er eine Clientverbindung akzeptiert.
Serverloser Modus: Ein Modus, in dem der Azure SignalR Service nur Clientverbindungen akzeptiert. Es ist keine Serververbindung gestattet.
Überblick
Azure SignalR Service definiert sieben Standard-Tarife für unterschiedliche Leistungskapazitäten. Dieser Leitfaden beantwortet die folgenden Fragen:
Was ist die typische Leistung des Azure SignalR-Diensts für jede Ebene (Einheit)?
Erfüllt der Azure SignalR Service meine Anforderungen an den Nachrichtendurchsatz (z. B. Senden von 100.000 Nachrichten pro Sekunde)?
Wie kann ich für mein spezifisches Szenario die richtige Ebene auswählen?
Welche Art von App-Server (VM-Größe) ist für mich geeignet? Wie viele sollte ich bereitstellen?
In diesem Leitfaden werden zunächst die Faktoren, die sich auf die Leistung auswirken, auf hoher Ebene erläutert. Anschließend werden für typische Anwendungsfälle die maximalen ein- und ausgehenden Nachrichten für die einzelnen Tarife dargestellt: Echo, Broadcast, An Gruppe senden und An Verbindung senden (Peer-zu-Peer-Chat).
Dieser Leitfaden kann nicht alle Szenarien abdecken (und verschiedene Anwendungsfälle, Nachrichtengrößen, Nachrichtensendemuster usw.). Aber er bietet einige hilfreiche Methoden:
- Bewerten Sie Ihre ungefähre Anforderung hinsichtlich der ein- oder ausgehenden Nachrichten.
- Suchen Sie die richtigen Tarife, indem Sie die Leistungstabelle überprüfen.
Leistungsübersicht
Dieser Abschnitt beschreibt die Methoden zur Leistungsauswertung und listet anschließend alle Faktoren auf, die sich auf die Leistung auswirken. Am Ende werden Methoden bereitgestellt, die Ihnen helfen, die Leistungsanforderungen auszuwerten.
Methodik
Durchsatz und Latenz sind zwei typische Aspekte der Leistungsüberprüfung. Für Azure SignalR Service verfügt jeder SKU-Tarif über eine eigene Richtlinie zur Durchsatzdrosselung. Die Richtlinie definiert den maximal zulässigen Durchsatz (ein- und ausgehende Bandbreite) als den maximal erreichten Durchsatz, wenn 99 Prozent der Nachrichten eine Latenzzeit von weniger als 1 Sekunde aufweisen.
Die Latenzzeit ist die Zeitspanne der Verbindung vom Senden der Nachricht bis zum Empfangen der Antwortnachricht von Azure SignalR Service. Nehmen Sie Echo als Beispiel. Jede Clientverbindung fügt der Nachricht einen Zeitstempel hinzu. Der Hub des App-Servers sendet die ursprüngliche Nachricht an den Client zurück. So kann die Weitergabeverzögerung von den einzelnen Clientverbindungen leicht berechnet werden. Der Zeitstempel wird für jede Nachricht in Broadcast, An Gruppe senden und An Verbindung senden angehängt.
Um Tausende von gleichzeitigen Clientverbindungen zu simulieren, werden in Azure mehrere virtuelle Computer in einem virtuellen privaten Netzwerk erstellt. Alle diese virtuellen Computer verbinden sich mit derselben Azure SignalR Service-Instanz.
Im Standardmodus von Azure SignalR Service werden App-Server-VMs in demselben virtuellen privaten Netzwerk wie Client-VMs bereitgestellt. Alle Client-VMs und App-Server-VMs werden im gleichen Netzwerk derselben Region bereitgestellt, um eine überregionale Latenz zu vermeiden.
Leistungsfaktoren
Die folgenden Faktoren wirken sich auf die SignalR-Leistung aus.
- SKU-Tarif (CPU/Arbeitsspeicher)
- Anzahl der Verbindungen
- Nachrichtengröße
- Nachrichtensendungsrate
- Transporttyp (WebSocket, Server-Sent-Event oder Long-Polling)
- Anwendungsfallszenario (Routingkosten)
- App-Server- und Dienstverbindungen (im Servermodus)
Computerressourcen
Theoretisch ist die Kapazität des Azure SignalR-Diensts durch Rechenressourcen begrenzt: CPU, Arbeitsspeicher und Netzwerk. Eine größere Anzahl von Verbindungen mit Azure SignalR Service führt z. B. dazu, dass der Dienst mehr Arbeitsspeicher benötigt. Für umfangreicheren Nachrichtenverkehr (z. B. ist jede Nachricht größer als 2.048 Byte) muss Azure SignalR Service mehr CPU-Zyklen für die Verarbeitung des Datenverkehrs aufwenden. In der Zwischenzeit setzt die Netzwerkbandbreite von Azure auch ein Limit für den maximalen Datenverkehr fest.
Transportart
Der Transporttyp ist ein weiterer Faktor, der sich auf die Leistung auswirkt. Die drei Typen sind:
- WebSocket: WebSocket ist ein bidirektionales und vollduplexes Kommunikationsprotokoll über eine einzelne TCP-Verbindung.
- Server-Sent-Event: Server-Sent-Event ist ein unidirektionales Protokoll zum Pushen von Nachrichten vom Server zum Client.
- Long-Polling: Long-Polling erfordert, dass die Clients regelmäßig Informationen vom Server über eine HTTP-Anforderung abrufen.
Für dieselbe API unter denselben Bedingungen weist WebSocket die beste Leistung auf, während Server-Sent-Event langsamer und Long-Polling die langsamste Option ist. WebSocket wird von Azure SignalR Service standardmäßig empfohlen.
Kosten für nachrichtenweiterleitung
Die Kosten für das Nachrichtenrouting begrenzen auch die Leistung. Azure SignalR Service spielt eine Rolle als Nachrichtenrouter, der die Nachricht von einer Reihe von Clients oder Servern an andere Clients oder Server weiterleitet. Ein anderes Szenario oder eine andere API erfordert eine andere Routingrichtlinie.
Bei Echo sendet der Client eine Nachricht an sich selbst, und das Routingziel ist ebenfalls er selbst. Dieses Muster weist die niedrigsten Routingkosten auf. Aber für Broadcast, An Gruppe senden und An Verbindung senden muss der Azure SignalR Service die Zielverbindungen über die intern verteilte Datenstruktur suchen. Diese zusätzliche Verarbeitung beansprucht mehr CPU, Arbeitsspeicher und Netzwerkbandbreite. Infolgedessen ist die Leistung geringer.
Im Standardmodus kann der App-Server auch für bestimmte Szenarien zu einem Engpass werden. Das Azure SignalR SDK muss den Hub aufrufen, während es über Heartbeatsignale eine Liveverbindung mit den einzelnen Clients aufrechterhält.
Im serverlosen Modus sendet der Client eine Nachricht nach HTTP-Post, die nicht so effizient ist wie WebSocket.
Protokoll
Ein weiterer Faktor ist das Protokoll: JSON und MessagePack. MessagePack ist kleiner und wird schneller als JSON bereitgestellt. MessagePack verbessert jedoch möglicherweise nicht die Leistung. Die Leistung von Azure SignalR Service ist für Protokolle nicht vertraulich, da die Nachrichtennutzlast während der Nachrichtenweiterleitung von Clients an Server oder umgekehrt nicht decodiert wird.
Suchen einer geeigneten SKU
Wie können Sie die ein- und ausgehende Kapazität bewerten oder herausfinden, welcher Tarif für einen bestimmten Anwendungsfall geeignet ist?
Gehen Sie davon aus, dass der App-Server leistungsfähig genug ist und nicht der Leistungsengpässe ist. Überprüfen Sie dann die maximale ein- und ausgehende Bandbreite für die einzelnen Tarife.
Schnellauswertung
Gehen Sie für eine schnelle Auswertung von den folgenden Standardeinstellungen aus:
- Der Transporttyp ist WebSocket.
- Die Nachrichtengröße ist 2.048 Bytes.
- Jede Sekunde wird eine Nachricht gesendet.
- Azure SignalR Service ist im Standardmodus.
Jeder Tarif hat seine eigene maximale ein- und ausgehende Bandbreite. Eine reibungslose Benutzererfahrung wird nicht garantiert, nachdem die eingehende oder ausgehende Verbindung den Grenzwert überschritten hat.
Echo gibt die maximale eingehende Bandbreite an, da sie die niedrigsten Routingkosten aufweist. Broadcast definiert die maximale Bandbreite der ausgehenden Nachrichten.
Überschreiten Sie nicht die in den folgenden beiden Tabellen hervorgehobenen Werte.
| Echo | Einheit 1 | Einheit 2 | Einheit 10 | Einheit 50 | Einheit 100 | Einheit 200 | Einheit 500 | Einheit 1000 |
|---|---|---|---|---|---|---|---|---|
| Verbindungen | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1,000,000 |
| Eingehende Bandbreite | 2 MBit/s | 4 MBit/s | 20 MBit/s | 100 MBit/s | 200 MBit/s | 400 MBit/s | 1.000 MBps | 2.000 MBps |
| Ausgehende Bandbreite | 2 MBit/s | 4 MBit/s | 20 MBit/s | 100 MBit/s | 200 MBit/s | 400 MBit/s | 1\.000 MBit/s | 2\.000 MBit/s |
| Broadcast | Einheit 1 | Einheit 2 | Einheit 10 | Einheit 50 | Einheit 100 | Einheit 200 | Einheit 500 | Einheit 1000 |
|---|---|---|---|---|---|---|---|---|
| Verbindungen | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1,000,000 |
| Eingehende Bandbreite | 4 KBit/s | 4 KBit/s | 4 KBit/s | 4 KBit/s | 4 KBit/s | 4 KBit/s | 4 KBit/s | 4 KBit/s |
| Ausgehende Bandbreite | 4 MBit/s | 8 MBit/s | 40 MBit/s | 200 MBit/s | 400 MBit/s | 800 MBps | 2.000 MBps | 4.000 MBps |
Eingehende Bandbreite und Ausgehende Bandbreite geben die gesamte Nachrichtengröße pro Sekunde an. Hier sind die entsprechenden Formeln:
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
inboundConnections: Die Anzahl der Verbindungen, die die Nachricht senden.
outboundConnections: Die Anzahl der Verbindungen, die die Nachricht empfangen.
messageSize: Die Größe einer einzelnen Nachricht (Durchschnittswert). Eine kleine Nachricht mit weniger als 1.024 Bytes hat eine Leistungsauswirkung, die einer 1.024-Byte-Nachricht ähnlich ist.
sendInterval: Die Zeit zum Senden einer Nachricht. Normalerweise entspricht dies eine Sekunde pro Nachricht, also wird jede Sekunde eine Nachricht gesendet. Ein kleineres Intervall bedeutet, dass mehr Nachrichten in einem Zeitraum gesendet werden. Beispielsweise bedeutet 0,5 Sekunden pro Nachricht, dass zwei Nachrichten jede Sekunde gesendet werden.
Connections: Der committete maximale Schwellenwert für den Azure SignalR Service für die einzelnen Tarife. Wenn die Verbindungsnummer weiter erhöht wird, leidet sie unter Verbindungsdrosselung.
Auswertung für komplexe Anwendungsfälle
Größere Nachrichten oder andere Sendungsrate
Der tatsächliche Anwendungsfall ist komplizierter. Es kann eine Nachricht senden, die größer als 2.048 Bytes ist, oder die Sendenachrichtrate ist keine Nachricht pro Sekunde. Nehmen wir die Sendung von Unit 100 als Beispiel an, um zu ermitteln, wie die Leistung ausgewertet wird.
Die folgende Tabelle zeigt einen realen Anwendungsfall von Broadcast. Aber die Nachrichtengröße, die Verbindungsanzahl und die Rate beim Senden der Nachrichten unterscheiden sich von dem, was wir im vorherigen Abschnitt angenommen haben. Die Frage ist, wie wir jedes dieser Elemente (Nachrichtengröße, Verbindungsanzahl oder Nachrichtensendungsrate) ableiten können, wenn nur zwei von ihnen bekannt sind.
| Broadcast | Nachrichtengröße | Gleichzeitige eingehende Nachrichten | Verbindungen | Sendeintervalle |
|---|---|---|---|---|
| 1 | 20 KB | 1 | 100.000 | 5 Sekunden |
| 2 | 256 KB | 1 | 8\.000 | 5 Sekunden |
Die folgende Formel lässt sich anhand der vorherigen Formel einfach ableiten:
outboundConnections = outboundBandwidth * sendInterval / messageSize
Für Einheit 100 beträgt die maximale ausgehende Bandbreite 400 MB aus der vorherigen Tabelle. Bei einer Nachrichtengröße von 20 KB sollten die maximalen ausgehenden Verbindungen 400 MB * 5 / 20 KB = 100.000 betragen, was dem tatsächlichen Wert entspricht.
Gemischte Anwendungsfälle
Der reale Anwendungsfall kombiniert typischerweise die vier grundlegenden Anwendungsfälle miteinander: Echo, Broadcast, An Gruppe senden und An Verbindung senden. Die von Ihnen verwendete Methodik zur Auswertung der Kapazität sieht wie folgt aus:
- Unterteilen Sie die gemischten Anwendungsfälle in vier grundlegende Anwendungsfälle.
- Berechnen Sie die maximale Bandbreite der eingehenden und ausgehenden Nachrichten, indem Sie die vorhergehenden Formeln separat verwenden.
- Summieren Sie die Bandbreitenberechnungen, um die gesamte maximale eingehende/ausgehende Bandbreite zu erhalten.
Wählen Sie dann den richtigen Tarif aus den Tabellen für die maximale eingehende/ausgehende Bandbreite aus.
Hinweis
Wenn Sie eine Nachricht an Hunderte oder Tausende kleine Gruppen senden oder wenn Tausende Clients sich gegenseitig eine Nachricht senden, werden die Routingkosten immer höher. Berücksichtigen Sie diese Auswirkungen.
Stellen Sie für den Anwendungsfall beim Senden einer Nachricht an Clients sicher, dass der App-Server nicht der Engpass ist. Der folgende Abschnitt „Fallstudie“ enthält Richtlinien zur Anzahl der erforderlichen App-Server und zur Anzahl der Serververbindungen, die Sie konfigurieren sollten.
Fallstudie
Die folgenden Abschnitte führen durch vier typische Anwendungsfälle für den WebSocket-Transport: Echo, Broadcast, An Gruppe senden und An Verbindung senden. Für jedes Szenario werden im Abschnitt die aktuelle ein- und ausgehende Kapazität für den Azure SignalR Service aufgelistet. Darüber hinaus werden die wichtigsten Faktoren erläutert, die sich auf die Leistung auswirken.
Im Standardmodus erstellt der App-Server fünf Serververbindungen mit Azure SignalR Service. Der App-Server verwendet standardmäßig das Azure SignalR Service-SDK. In den folgenden Leistungstestergebnissen werden die Serververbindungen auf 15 erhöht (oder mehr, falls eine Nachricht an eine große Gruppe gesendet wird).
Unterschiedliche Anwendungsfälle haben unterschiedliche Anforderungen an den App-Server. Broadcast benötigt eine geringe Anzahl von App-Servern. Echo oder An Verbindung senden benötigt viele App-Server.
In allen Anwendungsfällen beträgt die standardmäßige Nachrichtengröße 2.048 Byte und das Sendeintervall eine Sekunde.
Standardmodus
Clients, Web-App-Server und Azure SignalR Service sind im Standardmodus einbezogen. Jeder Client steht für eine einzelne Verbindung.
Echo
Zunächst stellt eine Web-App eine Verbindung mit Azure SignalR Service her. Anschließend stellen viele Clients eine Verbindung mit der Web-App her, die die Clients mit dem Zugriffstoken und dem Endpunkt an Azure SignalR Service weiterleitet. Dann stellen die Clients WebSocket-Verbindungen mit Azure SignalR Service her.
Nachdem alle Clients Verbindungen hergestellt haben, beginnen sie jede Sekunde eine Nachricht mit einem darin enthaltenen Zeitstempel an den jeweiligen Hub zu senden. Der Hub gibt die Nachricht an seinen ursprünglichen Client zurück. Jeder Client berechnet die Wartezeit, nachdem die Rückmeldung empfangen wurde.
Im folgenden Diagramm befinden sich 5 bis 8 (rot markierter Datenverkehr) in einer Schleife. Die Schleife hat eine Standardlaufzeit (5 Minuten) und erhält die Statistik aller Wartezeiten für die Nachrichten.
Das Verhalten von Echo bestimmt, dass die maximale eingehende Bandbreite gleich der maximalen ausgehenden Bandbreite ist. Details finden Sie in der folgenden Tabelle.
| Echo | Einheit 1 | Einheit 2 | Einheit 10 | Einheit 50 | Einheit 100 | Einheit 200 | Einheit 500 | Einheit 1000 |
|---|---|---|---|---|---|---|---|---|
| Verbindungen | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1,000,000 |
| Ein-/Ausgehende Nachrichten pro Sekunde | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1,000,000 |
| Ein-/Ausgehende Bandbreite | 2 MBit/s | 4 MBit/s | 20 MBit/s | 100 MBit/s | 200 MBit/s | 400 MBit/s | 1\.000 MBit/s | 2\.000 MBit/s |
In diesem Anwendungsfall ruft jeder Client den im App-Server definierten Hub auf. Der Hub ruft nur die Methode auf, die auf der ursprünglichen Clientseite definiert ist. Dieser Hub ist der leichteste Hub für Echo.
public void Echo(IDictionary<string, object> data)
{
Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
}
Selbst für diesen einfachen Hub ist der Datenverkehrsdruck auf dem App-Server mit zunehmender Arbeitslast durch eingehende Nachrichten groß, die von Echo verursacht werden. Dieser Datenverkehrsdruck erfordert viele App-Server für große SKU-Tarife. In der folgenden Tabelle ist die Anzahl der App-Server für die einzelnen Tarife aufgeführt.
| Echo | Einheit 1 | Einheit 2 | Einheit 10 | Einheit 50 | Einheit 100 | Einheit 200 | Einheit 500 | Einheit 1000 |
|---|---|---|---|---|---|---|---|---|
| Verbindungen | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1,000,000 |
| Anzahl der App-Server | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Hinweis
Die Anzahl der Clientverbindungen, die Nachrichtengröße, die Nachrichtensendungsrate, der SKU-Tarif und CPU/Arbeitsspeicher des App-Servers wirken sich auf die Gesamtleistung von Echo aus.
Broadcast
Bei Broadcast sendet die Web-App, wenn sie die Nachricht empfängt, an alle Clients. Je mehr Clients übertragen werden sollen, desto mehr Nachrichtenverkehr gibt es für alle Clients. Sehen Sie sich das folgende Diagramm an.
Eine geringe Anzahl von Clients sendet Nachrichten. Die Bandbreite für eingehende Nachrichten ist klein, aber die Bandbreite für ausgehende Nachrichten ist beträchtlich. Die Bandbreite für ausgehende Nachrichten steigt mit zunehmender Clientverbindungsanzahl oder Übertragungsrate.
Die folgende Tabelle fasst die maximalen Clientverbindungen, die Anzahl der eingehenden/ausgehenden Nachrichten und die Bandbreite zusammen.
| Broadcast | Einheit 1 | Einheit 2 | Einheit 10 | Einheit 50 | Einheit 100 | Einheit 200 | Einheit 500 | Einheit 1000 |
|---|---|---|---|---|---|---|---|---|
| Verbindungen | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1,000,000 |
| Eingehende Nachrichten pro Sekunde | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Ausgehende Nachrichten pro Sekunde | 2.000 | 4\.000 | 20,000 | 100.000 | 200.000 | 400.000 | 1,000,000 | 2\.000.000 |
| Eingehende Bandbreite | 4 KBit/s | 4 KBit/s | 4 KBit/s | 4 KBit/s | 4 KBit/s | 4 KBit/s | 4 KBit/s | 4 KBit/s |
| Ausgehende Bandbreite | 4 MBit/s | 8 MBit/s | 40 MBit/s | 200 MBit/s | 400 MBit/s | 800 MBit/s | 2\.000 MBit/s | 4.000 MBps |
Es gibt nicht mehr als vier übertragende Clients, die Nachrichten posten. Sie benötigen im Vergleich zu Echo weniger App-Server, da die Anzahl der eingehenden Nachrichten gering ist. Zwei App-Server genügen sowohl für SLA- als auch für Leistungsüberlegungen. Sie sollten jedoch die Standardserververbindungen erhöhen, um Ungleichgewichte zu vermeiden, insbesondere für Einheiten, die größer als 50 sind.
| Broadcast | Einheit 1 | Einheit 2 | Einheit 10 | Einheit 50 | Einheit 100 | Einheit 200 | Einheit 500 | Einheit 1000 |
|---|---|---|---|---|---|---|---|---|
| Verbindungen | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1,000,000 |
| Anzahl der App-Server | 1 | 1 | 1 | 2 | 2 | 4 | 10 | 20 |
Hinweis
Erhöhen Sie die Standardserververbindungen von 5 auf 40 auf jedem App-Server, um mögliche nicht ausgeglichene Serververbindungen zu Azure SignalR Service zu vermeiden.
Die Anzahl der Clientverbindungen, die Nachrichtengröße, die Nachrichtensendungsrate und der SKU-Tarif wirken sich auf die Gesamtleistung für Broadcast aus.
An Gruppe senden
Der Anwendungsfall An Gruppe senden weist ein ähnliches Datenverkehrsmuster auf wie Broadcast. Der Unterschied besteht darin, dass Clients, nachdem sie WebSocket-Verbindungen mit Azure SignalR Service hergestellt haben, Gruppen beitreten müssen, bevor sie eine Nachricht an eine bestimmte Gruppe senden können. Das folgende Diagramm veranschaulicht den Datenverkehrsfluss.
Anzahl der Gruppenmitglieder und Gruppen sind zwei Faktoren, die sich auf die Leistung auswirken. Es werden zwei Arten von Gruppen definiert, um die Analyse zu vereinfachen:
Kleine Gruppe: Jede Gruppe verfügt über 10 Verbindungen. Die Gruppenanzahl entspricht: (maximale Verbindungsanzahl) / 10. For example, for Unit 1, if there are 1.000 connection counts, then we have 1000 / 10 = 100 groups.
Große Gruppe: Die Gruppenanzahl ist immer 10. Die Anzahl der Gruppenmitglieder entspricht: (maximale Verbindungszahl) / 10. For example, for Unit 1, if there are 1.000 connection counts, then every group has 1000 / 10 = 100 members.
An Gruppe senden verursacht Routingkosten für Azure SignalR Service, da die Zielverbindungen über eine verteilte Datenstruktur gefunden werden müssen. Mit zunehmender Anzahl der sendenden Verbindungen steigen die Kosten.
Kleine Gruppe
Die Routingkosten sind für das Senden von Nachrichten an viele kleine Gruppen beträchtlich. Derzeit erreicht die Azure SignalR Service-Implementierung das Routingkostenlimit bei Einheit 50. Das Hinzufügen weiterer CPU und Arbeitsspeicher hilft nicht, sodass Unit 100 nicht durch den Entwurf weiter verbessert werden kann. Wenn Sie eine höhere eingehende Bandbreite benötigen, wenden Sie sich an den Kundensupport.
| An kleine Gruppe senden | Einheit 1 | Einheit 2 | Einheit 10 | Einheit 50 | Einheit 100 | Einheit 200 | Einheit 500 | Einheit 1000 |
|---|---|---|---|---|---|---|---|---|
| Verbindungen | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1,000,000 |
| Anzahl der Gruppenmitglieder | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Gruppenanzahl | 100 | 200 | 1.000 | 5\.000 | 10.000 | 20.000 | 50.000 | 100.000 |
| Eingehende Nachrichten pro Sekunde | 200 | 400 | 2.000 | 10.000 | 10.000 | 20.000 | 50.000 | 100.000 |
| Eingehende Bandbreite | 400 KBit/s | 800 KBit/s | 4 MBit/s | 20 MBit/s | 20 MBit/s | 40 MBit/s | 100 MBit/s | 200 MBit/s |
| Ausgehende Nachrichten pro Sekunde | 2.000 | 4\.000 | 20,000 | 100.000 | 100.000 | 200.000 | 500.000 | 1,000,000 |
| Ausgehende Bandbreite | 4 MBit/s | 8 MBit/s | 40 MBit/s | 200 MBit/s | 200 MBit/s | 400 MBit/s | 1\.000 MBit/s | 2\.000 MBit/s |
Viele Clientverbindungen rufen den Hub auf, sodass die Anzahl der App-Server auch für die Leistung entscheidend ist. In der folgenden Tabelle ist die jeweilige Anzahl der vorgeschlagenen App-Server aufgeführt.
| An kleine Gruppe senden | Einheit 1 | Einheit 2 | Einheit 10 | Einheit 50 | Einheit 100 | Einheit 200 | Einheit 500 | Einheit 1000 |
|---|---|---|---|---|---|---|---|---|
| Verbindungen | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1,000,000 |
| Anzahl der App-Server | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Hinweis
Die Anzahl der Clientverbindungen, die Nachrichtengröße, die Nachrichtensendungsrate, die Routingkosten, der SKU-Tarif und CPU/Arbeitsspeicher des App-Servers wirken sich auf die Gesamtleistung von An kleine Gruppe senden aus.
Die Gruppenanzahl, die in der Tabelle aufgeführte Gruppenmitgliedsanzahl sind keine harten Grenzwerte. Diese Parameterwerte werden ausgewählt, um ein stabiles Benchmarkszenario festzulegen. Beispielsweise ist es OK, jedem Conneciton eine unterschiedliche Gruppe zuzuweisen. Unter dieser Konfiguration befindet sich die Leistung in der Nähe des Sendens an die Verbindung.
Große Gruppe
Bei An große Gruppe senden wird die ausgehende Bandbreite zum Engpass, bevor die Routingkostengrenze erreicht wird. In der folgenden Tabelle ist die maximale ausgehende Bandbreite aufgeführt, die fast mit derjenigen für Broadcast identisch ist.
| An große Gruppe senden | Einheit 1 | Einheit 2 | Einheit 10 | Einheit 50 | Einheit 100 | Einheit 200 | Einheit 500 | Einheit 1000 |
|---|---|---|---|---|---|---|---|---|
| Verbindungen | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1,000,000 |
| Anzahl der Gruppenmitglieder | 100 | 200 | 500 | 1\.000 | 2.000 | 5\.000 | 10.000 | 20.000 |
| Gruppenanzahl | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Eingehende Nachrichten pro Sekunde | 20 | 20 | 20 | 20 | 20 | 20 | 20 | 20 |
| Eingehende Bandbreite | 40 KBit/s | 40 KBit/s | 40 KBit/s | 40 KBit/s | 40 KBit/s | 40 KBit/s | 40 KBit/s | 40 KBit/s |
| Ausgehende Nachrichten pro Sekunde | 2.000 | 4\.000 | 20,000 | 100.000 | 200.000 | 400.000 | 1,000,000 | 2\.000.000 |
| Ausgehende Bandbreite | 4 MBit/s | 8 MBit/s | 40 MBit/s | 200 MBit/s | 400 MBit/s | 800 MBit/s | 2\.000 MBit/s | 4.000 MBps |
Die Anzahl der sendenden Verbindungen ist nicht höher als 40. Die Belastung des App-Servers ist gering, sodass die empfohlene Anzahl von Web-Apps niedrig ist.
| An große Gruppe senden | Einheit 1 | Einheit 2 | Einheit 10 | Einheit 50 | Einheit 100 | Einheit 200 | Einheit 500 | Einheit 1000 |
|---|---|---|---|---|---|---|---|---|
| Verbindungen | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1,000,000 |
| Anzahl der App-Server | 1 | 1 | 2 | 2 | 2 | 4 | 10 | 20 |
Hinweis
Erhöhen Sie die Standardserververbindungen von 5 auf 40 auf jedem App-Server, um mögliche nicht ausgeglichene Serververbindungen zu Azure SignalR Service zu vermeiden.
Die Anzahl der Clientverbindungen, die Nachrichtengröße, die Nachrichtensendungsrate, die Routingkosten und der SKU-Tarif wirken sich auf die Gesamtleistung für An große Gruppe senden aus.
An Verbindung senden
Im Anwendungsfall An Verbindung senden ruft jeder Client beim Herstellen der Verbindungen mit Azure SignalR Service einen speziellen Hub auf, um eine eigene Verbindungs-ID zu erhalten. Der Leistungsbenchmark erfasst alle Verbindungs-IDs, mischt sie und ordnet sie allen Clients als Sendeziel neu zu. Die Clients senden die Nachricht weiterhin an die Zielverbindung, bis der Leistungstest abgeschlossen ist.
Die Routingkosten für An Verbindung senden sind vergleichbar mit den Kosten für An kleine Gruppe senden.
Da sich die Anzahl der Verbindungen erhöht, wird die Routingkosten zu einem kritischen Faktor, der die Gesamtleistung begrenzt. Insbesondere markiert Unit 20 den Schwellenwert, an dem der Dienst den Routingengpässe erreicht. Weitere Erhöhungen der Einheitenanzahl führen nicht zu Leistungsverbesserungen, es sei denn, es gibt eine Umstellung auf Premium_P2(Einheit >=100), wodurch Routingfunktionen verbessert werden.
Die folgende Tabelle ist eine statistische Zusammenfassung nach zahlreichen Durchläufen des Benchmarks An Verbindung senden.
| An Verbindung senden | Einheit 1 | Einheit 2 | Einheit 20 | Einheit 50 | Einheit 100 | Einheit 200 | Einheit 500 | Einheit 1000 |
|---|---|---|---|---|---|---|---|---|
| Verbindungen | 1.000 | 2.000 | 20,000 | 50.000 | 100.000 | 200.000 | 500.000 | 1,000,000 |
| Ein-/Ausgehende Nachrichten pro Sekunde | 1.000 | 2.000 | 20.000 | 20.000 | 20.000 | 40.000 | 100.000 | 200.000 |
| Ein-/Ausgehende Bandbreite | 2 MBit/s | 4 MBit/s | 40 MBit/s | 40 MBit/s | 40 MBit/s | 80 MBit/s | 200 MBit/s | 400 MBit/s |
Hinweis
Trotz der Stagnation bei eingehenden/ausgehenden Nachrichten pro Sekunde nach Einheit 20 nimmt die Kapazität für mehr Verbindungen weiter zu. In realen Geschäftsszenarien ist es häufig die Anzahl der Verbindungen, nicht deren gleichzeitige Nachrichtensendungsaktivität, die den Engpass bildet. Es ist ungewöhnlich, dass alle Verbindungen aktiv Nachrichten mit so hohen Frequenzen senden wie der Benchmarktest.
Dieser Anwendungsfall erfordert eine hohe Arbeitslast auf der Seite des App-Servers. Weitere Informationen zur Anzahl der vorgeschlagenen App-Server finden Sie in der folgenden Tabelle.
| An Verbindung senden | Einheit 1 | Einheit 2 | Einheit 10 | Einheit 50 | Einheit 100 | Einheit 200 | Einheit 500 | Einheit 1000 |
|---|---|---|---|---|---|---|---|---|
| Verbindungen | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1,000,000 |
| Anzahl der App-Server | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Hinweis
Die Anzahl der Clientverbindungen, die Nachrichtengröße, die Nachrichtensendungsrate, die Routingkosten, der SKU-Tarif und CPU/Arbeitsspeicher des App-Servers wirken sich auf die Gesamtleistung von An Verbindung senden aus.
ASP.NET SignalR
Azure SignalR Service bietet dieselbe Leistungskapazität für ASP.NET SignalR.
Serverloser Modus
Der serverlose Modus umfasst Clients und Azure SignalR Service. Jeder Client steht für eine einzelne Verbindung. Der Client sendet Nachrichten über die REST-API an einen anderen Client oder Broadcastmeldungen an alle Clients.
Das Senden von Nachrichten mit hoher Dichte über die REST-API ist nicht so effizient wie das Verwenden von WebSocket. Sie müssen dazu jedes Mal eine neue HTTP-Verbindung herstellen, und das ist im serverlosen Modus ein zusätzlicher Kostenfaktor.
Übertragen über die REST-API
Alle Clients stellen WebSocket-Verbindungen mit Azure SignalR Service her. Dann beginnen einige Clients mit der Übertragung über die REST-API. Das Senden von Nachrichten (eingehend) erfolgt über HTTP-Post, was im Vergleich zu WebSocket nicht effizient ist.
| Übertragen über die REST-API | Einheit 1 | Einheit 2 | Einheit 10 | Einheit 50 | Einheit 100 | Einheit 200 | Einheit 500 | Einheit 1000 |
|---|---|---|---|---|---|---|---|---|
| Verbindungen | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1,000,000 |
| Eingehende Nachrichten pro Sekunde | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Ausgehende Nachrichten pro Sekunde | 2.000 | 4\.000 | 20,000 | 100.000 | 200.000 | 400.000 | 1,000,000 | 2\.000.000 |
| Eingehende Bandbreite | 4 KBit/s | 4 KBit/s | 4 KBit/s | 4 KBit/s | 4 KBit/s | 4 KBit/s | 4 KBit/s | 4 KBit/s |
| Ausgehende Bandbreite | 4 MBit/s | 8 MBit/s | 40 MBit/s | 200 MBit/s | 400 MBit/s | 800 MBps | 2.000 MBps | 4.000 MBps |
Über die REST-API an Benutzer senden
Der Benchmark weist allen Clients Benutzernamen zu, bevor sie beginnen, eine Verbindung mit Azure SignalR Service herzustellen. Nachdem die Clients WebSocket-Verbindungen mit dem Azure SignalR Service hergestellt haben, beginnen sie damit, Nachrichten über HTTP-Post an andere Clients zu senden.
| Über die REST-API an Benutzer senden | Einheit 1 | Einheit 2 | Einheit 10 | Einheit 50 | Einheit 100 | Einheit 200 | Einheit 500 | Einheit 1000 |
|---|---|---|---|---|---|---|---|---|
| Verbindungen | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1,000,000 |
| Eingehende/ausgehende Nachrichten pro Sekunde | 200 | 400 | 2.000 | 10.000 | 20.000 | 40.000 | 100.000 | 200.000 |
| Eingehende/ausgehende Bandbreite | 400 KBit/s | 800 KBit/s | 4 MBit/s | 20 MBit/s | 40 MBit/s | 80 MBit/s | 200 MBit/s | 400 MBit/s |
Leistungstestumgebungen
Für alle oben aufgeführten Anwendungsfälle haben wir die Leistungstests in einer Azure-Umgebung durchgeführt. Wir haben höchstens 200 Client-VMs und 100-App-Server-VMs verwendet. Hier sind einige Details:
Größe der Client-VM: StandardDS2V2 (2 vCPUs, 7 G Arbeitsspeicher)
Größe der App-Server-VM: StandardF4sV2 (4 vCPUs, 8 G Arbeitsspeicher)
Azure SignalR-SDK-Serververbindungen: 15
Leistungstools
Leistungstools für Azure SignalR Service finden Sie auf GitHub.
Nächste Schritte
In diesem Artikel haben Sie einen Überblick über die Leistung von Azure SignalR Service in typischen Anwendungsfällen erhalten.
Weitere Informationen zu den internen Funktionen des Diensts und seiner Skalierung finden Sie in den folgenden Leitfäden: