Prestandaguide för Azure Web PubSub Service
En av de viktigaste fördelarna med att använda Azure Web PubSub Service är den enkla skalningen. I ett storskaligt scenario är prestanda en viktig faktor.
I den här guiden introducerar vi de faktorer som påverkar prestanda för Web PubSub-tjänsten. Vi beskriver typiska prestanda i olika användningsfall.
Snabbutvärdering med hjälp av mått
Innan vi går igenom de faktorer som påverkar prestandan ska vi först introducera ett enkelt sätt att övervaka trycket från din tjänst. Det finns ett mått som kallas serverbelastning på portalen.
Den visar databehandlingstrycket för din Azure Web PubSub-tjänst. Du kan testa i ditt eget scenario och kontrollera det här måttet för att avgöra om du vill skala upp. Svarstiden i Azure Web PubSub-tjänsten skulle förbli låg om serverbelastningen är under 70 %.
Kommentar
Om du använder enhet 50 eller större och ditt scenario främst skickar till små grupper (gruppstorlek <20) måste du kontrollera att skicka till en liten grupp för referens. I dessa scenarier finns det stora routningskostnader som inte ingår i serverbelastningen.
Nedan visas detaljerade begrepp för att utvärdera prestanda.
Termdefinitioner
Inkommande: Inkommande meddelande till Azure Web PubSub Service.
Utgående: Utgående meddelande från Azure Web PubSub Service.
Bandbredd: Den totala storleken på alla meddelanden på 1 sekund.
Översikt
Den här guiden besvarar följande frågor:
Vilken är den typiska prestandan för Azure Web PubSub Service för varje enhetsstorlek?
Uppfyller Azure Web PubSub Service mina krav för meddelandedataflöde (till exempel att skicka 100 000 meddelanden per sekund)?
Hur kan jag välja rätt enhetsstorlek för mitt specifika scenario?
För att besvara dessa frågor ger den här guiden först en förklaring på hög nivå av de faktorer som påverkar prestanda. Sedan visas det maximala antalet inkommande och utgående meddelanden för vanliga användningsfall: Skicka till grupper via Web PubSub-subprotocol, uppströms och rest-API .
Den här guiden kan inte omfatta alla scenarier (och olika användningsfall, meddelandestorlekar, mönster för meddelandesändning och så vidare). Men det ger viss grundläggande information för att förstå prestandabegränsningen.
Prestandainsikt
Det här avsnittet beskriver metodikerna för prestandautvärdering och listar sedan alla faktorer som påverkar prestanda. I slutändan innehåller den metoder som hjälper dig att utvärdera prestandakrav.
Metod
Dataflöde och svarstid är två typiska aspekter av prestandakontroll. Det maximala dataflödet (inkommande och utgående bandbredd) definieras som det maximala uppnådda dataflödet när 99 procent av meddelandena har svarstider som är mindre än 1 sekund. Det är ingen hård gräns.
Prestandafaktorer
Teoretiskt sett begränsas Azure Web PubSub Service-kapaciteten av beräkningsresurser: CPU, minne och nätverk. Fler anslutningar till Azure Web PubSub Service gör till exempel att tjänsten använder mer minne. För större meddelandetrafik (till exempel att varje meddelande är större än 2 048 byte) måste Azure Web PubSub Service spendera fler CPU-cykler för att bearbeta trafik.
Kostnaden för meddelanderoutning begränsar också prestanda. Azure Web PubSub Service spelar en roll som meddelandekö som dirigerar meddelandet mellan en uppsättning klienter. Ett annat scenario eller API kräver en annan routningsprincip.
För echo skickar klienten ett meddelande till uppströms och uppströms ekar meddelandet tillbaka till klienten. Det här mönstret har den lägsta routningskostnaden. Men för sändning, skicka till grupp och skicka till anslutning måste Azure Web PubSub Service leta upp målanslutningarna via den interna distribuerade datastrukturen. Den här extra bearbetningen använder mer processor-, minnes- och nätverksbandbredd. Därför är prestandan långsammare.
Sammanfattningsvis påverkar följande faktorer den inkommande och utgående kapaciteten:
Enhetsstorlek (CPU/minne)
Antal anslutningar
Meddelandestorlek
Skicka meddelandefrekvens
Användningsfall (routningskostnad)
Hitta rätt enhetsstorlek
Hur kan du utvärdera den inkommande/utgående kapaciteten eller ta reda på vilken enhetsstorlek som är lämplig för ett specifikt användningsfall?
Varje enhetsstorlek har sin egen maximala inkommande bandbredd och utgående bandbredd. En smidig användarupplevelse garanteras inte när den inkommande eller utgående trafiken överskrider tröskelvärdet.
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
- inkommande Anslut ions: Antalet anslutningar som skickar meddelandet.
- utgående Anslut ions: Antalet anslutningar som tar emot meddelandet.
- messageSize: Storleken på ett enda meddelande (genomsnittligt värde). Ett litet meddelande som är mindre än 1 024 byte har en prestandapåverkan som liknar ett meddelande på 1 024 byte.
- sendInterval: Intervallet för att skicka meddelanden. Till exempel innebär 1 sekund att skicka ett meddelande varje sekund. Ett mindre intervall innebär att fler meddelanden skickas under en tidsperiod. 0,5 sekunder innebär till exempel att två meddelanden skickas varje sekund.
- Anslut ions: Det incheckade maximala tröskelvärdet för Azure Web PubSub Service för varje enhetsstorlek. Anslut som överskrider tröskelvärdet begränsas.
Anta att uppströms är tillräckligt kraftfullt och inte är prestandaflaskhalsen. Kontrollera sedan den maximala inkommande och utgående bandbredden för varje enhetsstorlek.
Fallstudie
Följande avsnitt går igenom tre vanliga användningsfall: skicka till grupper via Web PubSub-subprotocol, utlösa CloudEvent och anropa rest api. För varje scenario listar avsnittet den aktuella inkommande och utgående kapaciteten för Azure Web PubSub Service. Det förklarar också de viktigaste faktorerna som påverkar prestanda.
I alla användningsfall är standardstorleken för meddelandet 2 048 byte och intervallet för meddelandesändning är 1 sekund.
Skicka till grupper via Web PubSub subprotocol
Tjänsten stöder en specifik delprotokol med namnet json.webpubsub.azure.v1, som ger klienterna möjlighet att publicera/prenumerera direkt i stället för en tur och retur till den överordnade servern. Det här scenariot är effektivt eftersom ingen server är inblandad och all trafik går via klienttjänstens WebSocket-anslutning.
Gruppmedlems- och gruppantal är två faktorer som påverkar prestanda. För att förenkla analysen definierar vi två typer av grupper:
- Stor grupp: Gruppnumret är alltid 10. Antalet gruppmedlemmar är lika med (maximalt antal anslutningar) /10. Om det till exempel finns 1 000 anslutningsantal för enhet 1 har varje grupp 1 000 /10 = 100 medlemmar.
- Liten grupp: Varje grupp har 10 anslutningar. Gruppnumret är lika med (maximalt antal anslutningar) /10. Om det till exempel finns 1 000 anslutningsantal för enhet 1 har vi 1 000 /10 = 100 grupper.
Skicka till grupp medför en routningskostnad till Azure Web PubSub Service eftersom den måste hitta målanslutningarna via en distribuerad datastruktur. I takt med att de sändande anslutningarna ökar ökar kostnaden.
Stor grupp
För att skicka till stor grupp blir den utgående bandbredden flaskhalsen innan den når gränsen för routningskostnad. I följande tabell visas den maximala utgående bandbredden.
| Skicka till stor grupp | Enhet 1 | Enhet 2 | Enhet 10 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| anslutningar | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Antal gruppmedlemmar | 100 | 200 | 1 000 | 5 000 | 10,000 | 5 000 | 10,000 | 20 000 |
| Antal grupper | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Inkommande meddelanden per sekund | 30 | 30 | 30 | 30 | 30 | 30 | 30 | 30 |
| Inkommande bandbredd | 60 KBIT/s | 60 KBIT/s | 60 KBIT/s | 60 KBIT/s | 60 KBIT/s | 60 KBIT/s | 60 KBIT/s | 60 KBIT/s |
| Utgående meddelanden per sekund | 3 000 | 6 000 | 30,000 | 150 000 | 300,000 | 600,000 | 1,500,000 | 3,000,000 |
| Utgående bandbredd | 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 |
Liten grupp
Routningskostnaden är betydande för att skicka meddelanden till många små grupper. Implementeringen av Azure Web PubSub Service når för närvarande kostnadsgränsen för routning på enhet 50. Att lägga till mer processor och minne hjälper inte, så enhet 100 kan inte förbättras ytterligare genom design. Om du behöver mer inkommande bandbredd måste du skala upp för att använda Premium_P2(enhet >100).
| Skicka till liten grupp | Enhet 1 | Enhet 2 | Enhet 10 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| anslutningar | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Antal gruppmedlemmar | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Antal grupper | 100 | 200 | 1 000 | 5 000 | 10,000 | 20 000 | 50,000 | 100,000 |
| Inkommande meddelanden per sekund | 200 | 400 | 2 000 | 10,000 | 10,000 | 20 000 | 50,000 | 100,000 |
| Inkommande bandbredd | 400 Kbit/s | 800 Kbit/s | 4 Mbit/s | 20 Mbit/s | 20 Mbit/s | 40 Mbit/s | 100 Mbit/s | 200 Mbit/s |
| Utgående meddelanden per sekund | 2 000 | 4 000 | 20 000 | 100,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Utgående bandbredd | 4 Mbit/s | 8 Mbit/s | 40 Mbit/s | 200 MBps | 200 Mbit/s | 400 Mbit/s | 1 000 Mbit/s | 2 000 Mbit/s |
Kommentar
Gruppantalet, antalet gruppmedlemmar som anges i tabellen är inte hårda gränser. Dessa parametervärden väljs för att upprätta ett stabilt benchmark-scenario.
Utlösa molnhändelse
Tjänsten levererar klienthändelser till den överordnade webhooken med hjälp av HTTP-protokollet CloudEvents.
För varje händelse formulerar den en HTTP POST-begäran till den registrerade uppströmsen och förväntar sig ett HTTP-svar.
Kommentar
Web PubSub stöder även HTTP 2.0 för uppströmshändelser som levererar. Resultatet nedan testas med HTTP 1.1. Om appservern stöder HTTP 2.0 blir prestandan bättre.
Echo
I det här fallet skriver appservern tillbaka det ursprungliga meddelandet i http-svaret. Ekots beteende avgör att den maximala inkommande bandbredden är lika med den maximala utgående bandbredden. Mer information finns i följande tabell.
| Echo | Enhet 1 | Enhet 2 | Enhet 10 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| anslutningar | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Inkommande/utgående meddelanden per sekund | 500 | 1 000 | 5 000 | 25,000 | 50,000 | 100,000 | 250 000 | 500,000 |
| Inkommande/utgående bandbredd | 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 tillhandahåller kraftfulla API:er för att hantera klienter och leverera realtidsmeddelanden.
Skicka till användare via REST API
Benchmark tilldelar användarnamn till alla klienter innan de börjar ansluta till Azure Web PubSub Service.
| Skicka till användare via REST API | Enhet 1 | Enhet 2 | Enhet 10 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| anslutningar | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Inkommande/utgående meddelanden per sekund | 180 | 360 | 1 800 | 9 000 | 18 000 | 36,000 | 90,000 | 180,000 |
| Inkommande/utgående bandbredd | 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 |
Sända via REST API
Bandbredden är densamma som för att skicka till stor grupp.
| Sända via REST API | Enhet 1 | Enhet 2 | Enhet 10 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| anslutningar | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Inkommande meddelanden per sekund | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 |
| Utgående meddelanden per sekund | 3 000 | 6 000 | 30,000 | 150 000 | 300,000 | 600,000 | 1,500,000 | 3,000,000 |
| Inkommande bandbredd | 6 Kbit/s | 6 Kbit/s | 6 Kbit/s | 6 Kbit/s | 6 Kbit/s | 6 Kbit/s | 6 Kbit/s | 6 Kbit/s |
| Utgående bandbredd | 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ästa steg
Använd dessa resurser för att börja skapa ett eget program: