Prestatiehandleiding voor Azure Web PubSub Service
Een van de belangrijkste voordelen van het gebruik van Azure Web PubSub Service is het gemak van schalen. In een grootschalig scenario is de prestaties een belangrijke factor.
In deze handleiding introduceren we de factoren die van invloed zijn op de prestaties van de Web PubSub-service. We beschrijven typische prestaties in verschillende use-casescenario's.
Snelle evaluatie met metrische gegevens
Voordat u de factoren doorloopt die van invloed zijn op de prestaties, introduceren we eerst een eenvoudige manier om de druk van uw service te bewaken. Er is een metrische waarde met de naam Server Load in de portal.
Hier ziet u de rekendruk van uw Azure Web PubSub-service. U kunt testen op uw eigen scenario en deze metrische gegevens controleren om te bepalen of u omhoog wilt schalen. De latentie in de Azure Web PubSub-service blijft laag als de serverbelasting lager is dan 70%.
Notitie
Als u eenheid 50 of groter gebruikt en uw scenario voornamelijk naar kleine groepen (groepsgrootte <20) wordt verzonden, moet u het verzenden naar een kleine groep controleren ter referentie. In deze scenario's zijn er grote routeringskosten die niet zijn opgenomen in de serverbelasting.
Hieronder ziet u gedetailleerde concepten voor het evalueren van prestaties.
Termendefinities
Binnenkomend: het binnenkomende bericht naar de Azure Web PubSub-service.
Uitgaand: het uitgaande bericht van de Azure Web PubSub-service.
Bandbreedte: de totale grootte van alle berichten in 1 seconde.
Overzicht
In deze handleiding worden de volgende vragen beantwoord:
Wat zijn de typische prestaties van de Azure Web PubSub Service voor elke eenheidsgrootte?
Voldoet Azure Web PubSub Service aan mijn vereisten voor berichtdoorvoer (bijvoorbeeld 100.000 berichten per seconde verzenden)?
Hoe kan ik voor mijn specifieke scenario de juiste eenheidsgrootte selecteren?
Om deze vragen te beantwoorden, geeft deze handleiding eerst een uitleg op hoog niveau van de factoren die van invloed zijn op de prestaties. Vervolgens ziet u de maximale inkomende en uitgaande berichten voor typische gebruiksvoorbeelden: Verzenden naar groepen via Web PubSub-subprotocol, upstream en rest API .
Deze handleiding kan niet alle scenario's behandelen (en verschillende use cases, berichtgrootten, bericht verzendende patronen, enzovoort). Maar het biedt enkele basisinformatie om inzicht te hebben in de prestatiebeperking.
Inzicht in prestaties
In deze sectie worden de methodologieën voor prestatieevaluatie beschreven en worden vervolgens alle factoren vermeld die van invloed zijn op de prestaties. Uiteindelijk biedt het methoden om u te helpen prestatievereisten te evalueren.
Methodologie
Doorvoer en latentie zijn twee typische aspecten van prestatiecontrole. De maximale doorvoer (binnenkomende en uitgaande bandbreedte) wordt gedefinieerd als de maximale bereikte doorvoer wanneer 99 procent van de berichten latentie heeft die kleiner is dan 1 seconde. Het is geen harde limiet.
Prestatiefactoren
Theoretisch wordt de capaciteit van de Azure Web PubSub-service beperkt door rekenbronnen: CPU, geheugen en netwerk. Meer verbindingen met Azure Web PubSub Service zorgen er bijvoorbeeld voor dat de service meer geheugen gebruikt. Voor groter berichtverkeer (bijvoorbeeld dat elk bericht groter is dan 2048 bytes), moet azure Web PubSub Service meer CPU-cycli uitgeven om verkeer te verwerken.
De kosten voor berichtroutering beperkt ook de prestaties. Azure Web PubSub Service speelt een rol als berichtbroker, waarmee het bericht wordt gerouteerd tussen een set clients. Voor een ander scenario of EEN ANDERE API is een ander routeringsbeleid vereist.
Voor echo verzendt de client een bericht naar de upstream en wordt het bericht weer naar de client verzonden. Dit patroon heeft de laagste routeringskosten. Maar voor broadcast, verzenden naar groep en verzenden naar verbinding moet Azure Web PubSub Service de doelverbindingen opzoeken via de interne gedistribueerde gegevensstructuur. Deze extra verwerking maakt gebruik van meer CPU, geheugen en netwerkbandbreedte. Hierdoor zijn de prestaties langzamer.
Kortom, de volgende factoren zijn van invloed op de inkomende en uitgaande capaciteit:
Eenheidsgrootte (CPU/geheugen)
Aantal verbindingen
Berichtgrootte
Verzendsnelheid van bericht
Use-casescenario (routeringskosten)
Een juiste eenheidsgrootte zoeken
Hoe kunt u de binnenkomende/uitgaande capaciteit evalueren of bepalen welke eenheidsgrootte geschikt is voor een specifieke use-case?
Elke eenheidsgrootte heeft een eigen maximale binnenkomende bandbreedte en uitgaande bandbreedte. Een soepele gebruikerservaring wordt niet gegarandeerd nadat het inkomende of uitgaande verkeer de drempelwaarde overschrijdt.
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
- inkomende Verbinding maken ions: het aantal verbindingen dat het bericht verzendt.
- uitgaande Verbinding maken ions: het aantal verbindingen dat het bericht ontvangt.
- messageSize: De grootte van één bericht (gemiddelde waarde). Een klein bericht dat kleiner is dan 1024 bytes, heeft een invloed op de prestaties die vergelijkbaar is met een bericht van 1024 bytes.
- sendInterval: het interval voor het verzenden van berichten. 1 seconde betekent bijvoorbeeld dat er elke seconde één bericht wordt verzonden. Een kleiner interval betekent dat er meer berichten in een bepaalde periode worden verzonden. 0,5 seconde betekent bijvoorbeeld dat er elke seconde twee berichten worden verzonden.
- Verbinding maken ions: de vastgelegde maximumdrempel voor Azure Web PubSub Service voor elke eenheidsgrootte. Verbinding maken ionen die de drempelwaarde overschrijden, worden beperkt.
Stel dat de upstream krachtig genoeg is en niet het prestatieknelpunt is. Controleer vervolgens de maximale binnenkomende en uitgaande bandbreedte voor elke eenheidsgrootte.
Casestudy
In de volgende secties worden drie typische gebruiksscenario's beschreven: verzenden naar groepen via web pubsubprotocol, het activeren van CloudEvent, het aanroepen van de REST API. Voor elk scenario bevat de sectie de huidige inkomende en uitgaande capaciteit voor Azure Web PubSub Service. Ook worden de belangrijkste factoren uitgelegd die van invloed zijn op de prestaties.
In alle gebruiksscenario's is de standaard berichtgrootte 2048 bytes en is het verzendinterval van het bericht 1 seconde.
Verzenden naar groepen via Web PubSub-subprotocol
De service ondersteunt een specifiek subprotocol dat wordt aangeroepen json.webpubsub.azure.v1, waardoor de clients rechtstreeks publiceren/abonneren in plaats van een retour naar de upstream-server. Dit scenario is efficiënt omdat er geen server betrokken is en al het verkeer via de websocket-verbinding van de clientservice verloopt.
Het aantal groepsleden en groepen zijn twee factoren die van invloed zijn op de prestaties. Om de analyse te vereenvoudigen, definiëren we twee soorten groepen:
- Grote groep: Het groepsnummer is altijd 10. Het aantal leden van de groep is gelijk aan (max. aantal verbindingen) / 10. Als er bijvoorbeeld 1.000 verbindingen zijn, heeft elke groep 1000 /10 = 100 leden.
- Kleine groep: elke groep heeft 10 verbindingen. Het groepsnummer is gelijk aan (max. aantal verbindingen) / 10. Als er bijvoorbeeld 1.000 verbindingsaantallen zijn, hebben we 1000 / 10 = 100 groepen.
Verzenden naar groep brengt routeringskosten naar Azure Web PubSub Service omdat deze de doelverbindingen moet vinden via een gedistribueerde gegevensstructuur. Naarmate de verzendende verbindingen toenemen, neemt de kosten toe.
Grote groep
Voor verzenden naar een grote groep wordt de uitgaande bandbreedte het knelpunt voordat de limiet voor routeringskosten wordt bereikt. De volgende tabel bevat de maximale uitgaande bandbreedte.
| Verzenden naar grote groep | Eenheid 1 | Eenheid 2 | Eenheid 10 | Eenheid 50 | Eenheid 100 | Eenheid 200 | Eenheid 500 | Eenheid 1000 |
|---|---|---|---|---|---|---|---|---|
| Connecties | 1.000 | 2.000 | 10,000 | 50,000 | 100.000 | 200.000 | 500,000 | 1.000.000 |
| Aantal groepsleden | 100 | 200 | 1.000 | 5.000 | 10,000 | 5.000 | 10,000 | 20,000 |
| Aantal groepen | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Binnenkomende berichten per seconde | 30 | 30 | 30 | 30 | 30 | 30 | 30 | 30 |
| Binnenkomende bandbreedte | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps |
| Uitgaande berichten per seconde | 3.000 | 6.000 | 30,000 | 150.000 | 300,000 | 600,000 | 1,500,000 | 3,000,000 |
| Uitgaande bandbreedte | 6 MBps | 12 MBps | 60 MBps | 300 MBps | 600 MBps | 1.200 MBps | 3000 MBps | 6.000 MBps |
Kleine groep
De routeringskosten zijn aanzienlijk voor het verzenden van berichten naar veel kleine groepen. Momenteel bereikt de implementatie van de Azure Web PubSub-service de limiet voor routeringskosten bij eenheid 50. Het toevoegen van meer CPU en geheugen helpt niet, dus Eenheid 100 kan niet verder worden verbeterd door het ontwerp. Als u meer binnenkomende bandbreedte nodig hebt, moet u omhoog schalen om Premium_P2 (eenheid >100) te gebruiken.
| Verzenden naar kleine groep | Eenheid 1 | Eenheid 2 | Eenheid 10 | Eenheid 50 | Eenheid 100 | Eenheid 200 | Eenheid 500 | Eenheid 1000 |
|---|---|---|---|---|---|---|---|---|
| Connecties | 1.000 | 2.000 | 10,000 | 50,000 | 100.000 | 200.000 | 500,000 | 1.000.000 |
| Aantal groepsleden | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Aantal groepen | 100 | 200 | 1.000 | 5.000 | 10,000 | 20,000 | 50,000 | 100.000 |
| Binnenkomende berichten per seconde | 200 | 400 | 2.000 | 10,000 | 10,000 | 20,000 | 50,000 | 100.000 |
| Binnenkomende bandbreedte | 400 KBps | 800 KBps | 4 Mbps | 20 MBps | 20 MBps | 40 MBps | 100 MBps | 200 MBps |
| Uitgaande berichten per seconde | 2.000 | 4000 | 20,000 | 100.000 | 100.000 | 200.000 | 500,000 | 1.000.000 |
| Uitgaande bandbreedte | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 200 MBps | 400 MBps | 1000 MBps | 2000 MBps |
Notitie
Het aantal groepen, het aantal groepsleden dat in de tabel wordt vermeld, zijn geen vaste limieten. Deze parameterwaarden worden geselecteerd om een stabiel benchmarkscenario tot stand te brengen.
Cloud event activeren
Service levert clientevenementen aan de upstream-webhook met behulp van het HTTP-protocol van CloudEvents.
Voor elke gebeurtenis formuleert het een HTTP POST-aanvraag naar de geregistreerde upstream en verwacht een HTTP-antwoord.
Notitie
Web PubSub ondersteunt ook HTTP 2.0 voor upstream-gebeurtenissen die worden geleverd. Het onderstaande resultaat wordt getest met HTTP 1.1. Als uw app-server HTTP 2.0 ondersteunt, zijn de prestaties beter.
Echo
In dit geval schrijft de app-server het oorspronkelijke bericht terug in het HTTP-antwoord. Het gedrag van echo bepaalt dat de maximale binnenkomende bandbreedte gelijk is aan de maximale uitgaande bandbreedte. Zie de volgende tabel voor meer informatie.
| Echo | Eenheid 1 | Eenheid 2 | Eenheid 10 | Eenheid 50 | Eenheid 100 | Eenheid 200 | Eenheid 500 | Eenheid 1000 |
|---|---|---|---|---|---|---|---|---|
| Connecties | 1.000 | 2.000 | 10,000 | 50,000 | 100.000 | 200.000 | 500,000 | 1.000.000 |
| Inkomende/uitgaande berichten per seconde | 500 | 1.000 | 5.000 | 25,000 | 50,000 | 100.000 | 250.000 | 500,000 |
| Binnenkomende/uitgaande bandbreedte | 1 MBps | 2 MBps | 10 MBps | 50 MBps | 100 MBps | 200 MBps | 500 MBps | 1000 MBps |
REST-API
Azure Web PubSub biedt krachtige API's voor het beheren van clients en het leveren van realtime berichten.
Verzenden naar gebruiker via REST API
De benchmark wijst gebruikersnamen toe aan alle clients voordat ze verbinding maken met Azure Web PubSub Service.
| Verzenden naar gebruiker via REST API | Eenheid 1 | Eenheid 2 | Eenheid 10 | Eenheid 50 | Eenheid 100 | Eenheid 200 | Eenheid 500 | Eenheid 1000 |
|---|---|---|---|---|---|---|---|---|
| Connecties | 1.000 | 2.000 | 10,000 | 50,000 | 100.000 | 200.000 | 500,000 | 1.000.000 |
| Inkomende/uitgaande berichten per seconde | 180 | 360 | 1800 | 9.000 | 18.000 | 36,000 | 90,000 | 180,000 |
| Binnenkomende/uitgaande bandbreedte | 360 KBps | 720 KBps | 3.6 MBps | 18 MBps | 36 MBps | 72 MBps | 180 MBps | 360 MBps |
Uitzenden via REST API
De bandbreedte is hetzelfde als die voor verzenden naar een grote groep.
| Uitzenden via REST API | Eenheid 1 | Eenheid 2 | Eenheid 10 | Eenheid 50 | Eenheid 100 | Eenheid 200 | Eenheid 500 | Eenheid 1000 |
|---|---|---|---|---|---|---|---|---|
| Connecties | 1.000 | 2.000 | 10,000 | 50,000 | 100.000 | 200.000 | 500,000 | 1.000.000 |
| Binnenkomende berichten per seconde | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 |
| Uitgaande berichten per seconde | 3.000 | 6.000 | 30,000 | 150.000 | 300,000 | 600,000 | 1,500,000 | 3,000,000 |
| Binnenkomende bandbreedte | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps |
| Uitgaande bandbreedte | 6 MBps | 12 MBps | 60 MBps | 300 MBps | 600 MBps | 1.200 MBps | 3000 MB | 6000 MB |
Volgende stappen
Gebruik deze resources om te beginnen met het bouwen van uw eigen toepassing: