Dela via


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.

Skärmbild av serverinläsningsmåttet för Azure Web PubSub på portalen. Måttet visar att serverbelastningen är ungefär 8 procents användning.

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.

Diagram som visar arbetsflödet skicka till grupp.

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.

Den överordnade webhooken

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.

Diagram som visar det övergripande arbetsflödet för Web PubSub-tjänsten med hjälp av REST-API:er.

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: