Leistungsleitfaden für den Azure Web PubSub-Dienst
Einer der wichtigsten Vorteile der Verwendung von Azure Web PubSub Service ist die einfache Skalierung. In einem Szenario mit großem Umfang ist die Leistung ein wichtiger Faktor.
In diesem Leitfaden werden die Faktoren vorgestellt, die sich auf die Leistung des Web PubSub-Diensts auswirken. Wir beschreiben typische Leistung in unterschiedlichen Anwendungsfallszenarien.
Schnelle Auswertung mithilfe von Metriken
Bevor Sie die Faktoren durchgehen, die sich auf die Leistung auswirken, lassen Sie uns zunächst eine einfache Möglichkeit zum Überwachen des Drucks vorstellen, unter dem Ihr Dienst steht. Es gibt eine Metrik namens Serverlast im Portal.
Sie zeigt den Computingdruck, unter dem Ihr Azure Web PubSub-Dienst steht. Sie können Ihr eigenes Szenario testen und diese Metrik überprüfen, um zu entscheiden, ob eine Hochskalierung erfolgen soll. Die Latenz innerhalb des Azure Web PubSub-Diensts würde niedrig bleiben, wenn die Serverlast unter 70 % liegt.
Hinweis
Wenn Sie Einheit 50 oder größer verwenden und Ihr Szenario hauptsächlich an kleine Gruppen (Gruppengröße <20) sendet, müssen Sie als Referenz das Senden an kleine Gruppe überprüfen. In diesen Szenarien fallen hohe Routingkosten an, die nicht in der Serverlast enthalten sind.
Nachfolgend finden Sie detaillierte Konzepte zur Bewertung der Leistung.
Begriffsdefinitionen
Eingehend: Die eingehende Nachricht an den Azure Web PubSub-Dienst.
Ausgehend: Die ausgehende Nachricht vom Azure Web PubSub-Dienst.
Bandbreite: Die Gesamtgröße aller Nachrichten in einer Sekunde.
Übersicht
Dieser Leitfaden beantwortet die folgenden Fragen:
Was ist die typische Leistung des Azure Web PubSub-Diensts für die einzelnen Einheitsgrößen?
Erfüllt der Azure Web PubSub-Dienst meine Anforderungen an den Nachrichtendurchsatz (z. B. Senden von 100.000 Nachrichten pro Sekunde)?
Wie kann ich für mein spezifisches Szenario die richtige Einheitsgröße auswählen?
In diesem Leitfaden werden zunächst die Faktoren, die sich auf die Leistung auswirken, auf hoher Ebene erläutert. Anschließend werden die maximalen eingehenden und ausgehenden Nachrichten für typische Anwendungsfälle veranschaulicht: An Gruppen senden über das Web PubSub-Unterprotokol, Upstream und Rest-API.
Dieser Leitfaden kann nicht alle Szenarien abdecken (und verschiedene Anwendungsfälle, Nachrichtengrößen, Nachrichtensendemuster usw.). Er enthält jedoch einige grundlegende Informationen, um die Leistungseinschränkung zu verstehen.
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. Der maximalen Durchsatz (eingehende und ausgehende Bandbreite) wird als maximal erreichter Durchsatz definiert, wenn 99 Prozent der Nachrichten eine Latenz aufweisen, die weniger als 1 Sekunde beträgt. 2 GB ist keine harte Grenze.
Leistungsfaktoren
Theoretisch ist die Kapazität des Azure Web PubSub-Diensts durch Berechnungsressourcen begrenzt: CPU, Arbeitsspeicher und Netzwerk. Eine größere Anzahl von Verbindungen mit dem Azure Web PubSub-Dienst führt beispielsweise dazu, dass der Dienst mehr Arbeitsspeicher benötigt. Für umfangreicheren Nachrichtenverkehr (z. B. wenn jede Nachricht größer als 2.048 Byte ist) muss der Azure Web PubSub-Dienst mehr CPU-Zyklen für die Verarbeitung des Datenverkehrs aufwenden.
Die Kosten für das Nachrichtenrouting begrenzen auch die Leistung. Der Azure Web PubSub-Dienst dient als Nachrichtenbroker, der die Nachricht zwischen mehreren Clients weiterleitet. Ein anderes Szenario oder eine andere API erfordert eine andere Routingrichtlinie.
Bei echo sendet der Client eine Nachricht an den Upstream, der die Nachricht an den Client zurückgibt. Dieses Muster weist die niedrigsten Routingkosten auf. Aber für Broadcast, An Gruppe senden und An Verbindung senden muss der Azure Web PubSub-Dienst die Zielverbindungen über die intern verteilte Datenstruktur suchen. Diese zusätzliche Verarbeitung beansprucht mehr CPU, Arbeitsspeicher und Netzwerkbandbreite. Infolgedessen ist die Leistung geringer.
Zusammenfassend lässt sich sagen, dass sich die folgenden Faktoren auf die ein- und ausgehenden Kapazitäten auswirken:
Einheitengröße (CPU/Arbeitsspeicher)
Anzahl der Verbindungen
Nachrichtengröße
Nachrichtensendungsrate
Anwendungsfallszenario (Routingkosten)
Finden der richtigen Einheitsgröße
Wie können Sie die ein- und ausgehende Kapazität bewerten oder herausfinden, welche Einheitengröße für einen bestimmten Anwendungsfall geeignet ist?
Jede Einheitsgröße verfügt über eine eigene maximale eingehende und ausgehende Bandbreite. Nachdem der eingehende oder ausgehende Datenverkehr den Schwellenwert überschritten hat, ist keine einwandfreie Nutzung gewährleistet.
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: Dies ist das Intervall zum Senden von Nachrichten. Wenn beispielsweise eine Sekunde festgelegt ist, wird jede Sekunde eine Nachricht gesendet. Ein kürzeres Intervall bedeutet, dass mehr Nachrichten in einem Zeitraum gesendet werden. So bedeutet beispielsweise ein Wert von 0,5 Sekunden, dass pro Sekunde zwei Nachrichten gesendet werden.
- Connections: Der committete maximale Schwellenwert für den Azure Web PubSub-Dienst für jede Einheitsgröße. Verbindungen, die den Schwellenwert überschreiten, werden gedrosselt.
Angenommen, der Upstream ist leistungsstark genug und nicht der Leistungsengpass. Überprüfen Sie dann die maximale ein- und ausgehende Bandbreite für jede Einheitsgröße.
Fallstudie
In den folgenden Abschnitten werden drei typische Anwendungsfälle beschrieben: Senden an Gruppen über das Web PubSub-Unterprotokoll, Auslösen von CloudEvent und Abrufen der REST-API. Für jedes Szenario werden im Abschnitt die aktuelle ein- und ausgehende Kapazität für den Azure Web PubSub-Dienst aufgelistet. Darüber hinaus werden die wichtigsten Faktoren erläutert, die sich auf die Leistung auswirken.
In allen Anwendungsfällen beträgt die standardmäßige Nachrichtengröße 2.048 Byte und das Sendeintervall eine Sekunde.
Senden an Gruppen über das Web PubSub-Unterprotokoll
Der Dienst unterstützt das Unterprotokoll namens json.webpubsub.azure.v1, das es den Clients ermöglicht, Nachrichten direkt zu veröffentlichen bzw. zu abonnieren, ohne einen Roundtrip zum Upstreamserver durchführen zu müssen. Dieses Szenario ist effizient, da kein Server beteiligt ist und der gesamte Datenverkehr die WebSocket-Clientdienstverbindung durchläuft.
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:
- Große Gruppe: Die Gruppenanzahl ist immer 10. Die Anzahl der Gruppenmitglieder entspricht: (maximale Verbindungszahl) / 10. Wenn es z. B. für Unit 1 1.000 Verbindungen gibt, dann besteht jede Gruppe aus 1.000 / 10 = 100 Mitgliedern.
- Kleine Gruppe: Jede Gruppe verfügt über 10 Verbindungen. Die Gruppenanzahl entspricht: (maximale Verbindungsanzahl) / 10. Wenn es z. B. für Unit 1 1.000 Verbindungen gibt, dann sind das 1.000 / 10 = 100 Gruppen.
An Gruppe senden verursacht Routingkosten für den Azure Web PubSub-Dienst, da die Zielverbindungen über eine verteilte Datenstruktur gefunden werden müssen. Mit zunehmender Anzahl der sendenden Verbindungen steigen die Kosten.
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 Bandbreite für ausgehenden Datenverkehr aufgeführt.
| 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 | 1.000 | 5\.000 | 10.000 | 5\.000 | 10.000 | 20.000 |
| Gruppenanzahl | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Eingehende Nachrichten pro Sekunde | 30 | 30 | 30 | 30 | 30 | 30 | 30 | 30 |
| Eingehende Bandbreite | 60 KBit/s | 60 KBit/s | 60 KBit/s | 60 KBit/s | 60 KBit/s | 60 KBit/s | 60 KBit/s | 60 KBit/s |
| Ausgehende Nachrichten pro Sekunde | 3,000 | 6.000 | 30.000 | 150.000 | 300.000 | 600.000 | 1\.500.000 | 3,000,000 |
| Ausgehende Bandbreite | 6 MBit/s | 12 MBit/s | 60 MBit/s | 300 MBit/s | 600 MBit/s | 1.200 MBit/s | 3.000 MBit/s | 6.000 MBit/s |
Kleine Gruppe
Die Routingkosten sind für das Senden von Nachrichten an viele kleine Gruppen beträchtlich. Derzeit erreicht die Implementierung des Azure Web PubSub-Diensts die Routingkostengrenze bei Unit50. Das Erhöhen der Anzahl von CPUs und Arbeitsspeicher hilft in diesem Fall nicht, daher kann Einheit 100 vorsätzlich nicht verbessert werden. Wenn Sie mehr eingehende Bandbreite benötigen, müssen Sie Premium_P2(Einheit >100) skalieren.
| 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 |
Hinweis
Die Gruppenanzahl, die in der Tabelle aufgeführte Gruppenmitgliederanzahl sind keine harten Grenzwerte. Diese Parameterwerte werden ausgewählt, um ein stabiles Benchmarkszenario festzulegen.
Auslösen eines Cloudereignisses
Der Dienst übergibt Clientereignisse mithilfe des CloudEvents-HTTP-Protokolls an den Upstreamwebhook.
Für jedes Ereignis formuliert er eine HTTP-POST-Anforderung an den registrierten Upstream und erwartet eine HTTP-Antwort.
Hinweis
Web PubSub unterstützt auch HTTP 2.0 für die Bereitstellung von Upstreamereignissen. Das folgende Ergebnis wird mit HTTP 1.1 getestet. Wenn Ihr App-Server HTTP 2.0 unterstützt, ist die Leistung besser.
Echo
In diesem Fall schreibt der App-Server die ursprüngliche Nachricht zurück in die HTTP-Antwort. 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 | 500 | 1.000 | 5.000 | 25.000 | 50.000 | 100.000 | 250.000 | 500.000 |
| Ein-/Ausgehende Bandbreite | 1 MBit/s | 2 MBit/s | 10 MBit/s | 50 MBit/s | 100 MBit/s | 200 MBit/s | 500 MBit/s | 1.000 MBit/s |
REST-API
Azure Web PubSub bietet leistungsstarke APIs zum Verwalten von Clients und Senden von Echtzeitnachrichten.
Über die REST-API an Benutzer senden
Die Benchmark weist allen Clients Benutzernamen zu, bevor diese mit dem Herstellen einer Verbindung mit dem Azure Web PubSub-Dienst beginnen.
| Ü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 |
| Ein-/Ausgehende Nachrichten pro Sekunde | 180 | 360 | 1\.800 | 9.000 | 18.000 | 36.000 | 90.000 | 180.000 |
| Ein-/Ausgehende Bandbreite | 360 KBit/s | 720 KBit/s | 3,6 MBit/s | 18 MBit/s | 36 MBit/s | 72 MBit/s | 180 MBit/s | 360 MBit/s |
Übertragen über die REST-API
Die Bandbreite entspricht der für An große Gruppe senden.
| Ü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 | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 |
| Ausgehende Nachrichten pro Sekunde | 3,000 | 6.000 | 30.000 | 150.000 | 300.000 | 600.000 | 1\.500.000 | 3,000,000 |
| Eingehende Bandbreite | 6 KBit/s | 6 KBit/s | 6 KBit/s | 6 KBit/s | 6 KBit/s | 6 KBit/s | 6 KBit/s | 6 KBit/s |
| Ausgehende Bandbreite | 6 MBit/s | 12 MBit/s | 60 MBit/s | 300 MBit/s | 600 MBit/s | 1.200 MBit/s | 3.000 MB | 6.000 MB |
Nächste Schritte
Erstellen Sie mithilfe dieser Ressourcen Ihre eigene Anwendung: