Prestandaguide för Azure SignalR Service
En av de viktigaste fördelarna med att använda Azure SignalR Service är hur enkelt det är att skala SignalR-program. I ett storskaligt scenario är prestanda en viktig faktor.
I den här artikeln beskrivs:
- De faktorer som påverkar SignalR-programmets prestanda.
- Typiska prestanda i olika användningsfall.
- Den miljö och de verktyg som du kan använda för att generera en prestandarapport.
Snabbutvärdering med hjälp av mått
Du kan enkelt övervaka din tjänst i Azure-portalen. På sidan Mått i SignalR-instansen kan du välja måtten Server load för att se "trycket" för din tjänst.
Diagrammet visar databehandlingstrycket för SignalR-tjänsten. Du kan testa ditt scenario och kontrollera det här måttet för att avgöra om du vill skala upp. Svarstiden i SignalR-tjänsten är fortfarande låg om serverbelastningen är under 70 %.
Kommentar
Om du använder enhet 50 eller större och ditt scenario huvudsakligen skickar till små grupper (gruppstorlek <20) eller en enda anslutning, måste du kontrollera att skicka till en liten grupp eller skicka till anslutningen för referens. I dessa scenarier finns det stora routningskostnader som inte ingår i serverbelastningen.
Termdefinitioner
Inkommande: Inkommande meddelande till Azure SignalR Service.
Utgående: Utgående meddelande från Azure SignalR Service.
Bandbredd: Den totala storleken på alla meddelanden på 1 sekund.
Standardläge: Standardläge när en Azure SignalR Service-instans skapas. Azure SignalR Service förväntar sig att appservern upprättar en anslutning till den innan den accepterar någon klientanslutning.
Serverlöst läge: Ett läge där Azure SignalR Service endast accepterar klientanslutningar. Ingen serveranslutning tillåts.
Översikt
Azure SignalR Service definierar sju standardnivåer för olika prestandakapaciteter. Den här guiden besvarar följande frågor:
Vad är den typiska Azure SignalR Service-prestandan för varje nivå (enhet)?
Uppfyller Azure SignalR Service mina krav för meddelandeflöde (till exempel att skicka 100 000 meddelanden per sekund)?
Hur kan jag välja rätt nivå för mitt specifika scenario?
Vilken typ av appserver (VM-storlek) passar mig? Hur många av dem ska jag distribuera?
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 varje nivå för vanliga användningsfall: eko, sändning, skicka till grupp och skicka till anslutning (peer-to-peer-chatt).
Den här guiden kan inte omfatta alla scenarier (och olika användningsfall, meddelandestorlekar, mönster för meddelandesändning och så vidare). Men den innehåller några metoder som hjälper dig:
- Utvärdera ditt ungefärliga krav för inkommande eller utgående meddelanden.
- Hitta rätt nivåer genom att kontrollera prestandatabellen.
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. För Azure SignalR Service har varje SKU-nivå en egen princip för dataflödesbegränsning. Principen definierar det maximala tillåtna dataflödet (inkommande och utgående bandbredd) som det maximala uppnådda dataflödet när 99 procent av meddelandena har svarstid som är mindre än 1 sekund.
Svarstiden är tidsintervallet från anslutningen som skickar meddelandet till att ta emot svarsmeddelandet från Azure SignalR Service. Ta eko som exempel. Varje klientanslutning lägger till en tidsstämpel i meddelandet. Appserverns hubb skickar tillbaka det ursprungliga meddelandet till klienten. Spridningsfördröjningen beräknas därför enkelt av varje klientanslutning. Tidsstämpeln är kopplad för varje meddelande i sändning, skicka till grupp och skicka till anslutning.
För att simulera tusentals samtidiga klientanslutningar skapas flera virtuella datorer i ett virtuellt privat nätverk i Azure. Alla dessa virtuella datorer ansluter till samma Azure SignalR Service-instans.
I standardläget för Azure SignalR Service distribueras de virtuella appserverdatorerna i samma virtuella privata nätverk som virtuella klientdatorer. Alla virtuella klientdatorer och virtuella appserverdatorer distribueras i samma nätverk i samma region för att undvika fördröjning mellan regioner.
Prestandafaktorer
Följande faktorer påverkar SignalR-prestanda.
- SKU-nivå (CPU/minne)
- Antal anslutningar
- Meddelandestorlek
- Skicka meddelandefrekvens
- Transporttyp (WebSocket, Server-Sent-Event eller Long-Polling)
- Användningsfall (routningskostnad)
- Appserver- och tjänstanslutningar (i serverläge)
Datorresurser
Teoretiskt sett begränsas Azure SignalR Service-kapaciteten av beräkningsresurser: CPU, minne och nätverk. Fler anslutningar till Azure SignalR Service gör till exempel att tjänsten använder mer minne. För större meddelandetrafik (till exempel är varje meddelande större än 2 048 byte) måste Azure SignalR Service spendera fler CPU-cykler för att bearbeta trafik. Under tiden inför Azure-nätverksbandbredden också en gräns för maximal trafik.
Transporttyp
Transporttypen är en annan faktor som påverkar prestanda. De tre typerna är:
- WebSocket: WebSocket är ett dubbelriktat och fullständigt duplex kommunikationsprotokoll över en enda TCP-anslutning.
- Server-Sent-Event: Server-Sent-Event är ett enkelriktat protokoll för att skicka meddelanden från server till klient.
- Long-Polling: Long-Polling kräver att klienterna regelbundet avsöker information från servern via en HTTP-begäran.
För samma API under samma förhållanden har WebSocket bästa prestanda, Server-Sent-Event är långsammare och Long-Polling är långsammast. Azure SignalR Service rekommenderar WebSocket som standard.
Kostnader för meddelanderoutning
Kostnaden för meddelanderoutning begränsar också prestanda. Azure SignalR Service spelar en roll som en meddelanderouter som dirigerar meddelandet från en uppsättning klienter eller servrar till andra klienter eller servrar. Ett annat scenario eller API kräver en annan routningsprincip.
För echo skickar klienten ett meddelande till sig själv och routningsmålet är också sig självt. 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 SignalR 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.
I standardläget kan appservern också bli en flaskhals för vissa scenarier. Azure SignalR SDK måste anropa hubben, medan den upprätthåller en live-anslutning med varje klient via pulsslagssignaler.
I serverlöst läge skickar klienten ett meddelande via HTTP-inlägg, som inte är lika effektivt som WebSocket.
Protokoll
En annan faktor är protokoll: JSON och MessagePack. MessagePack är mindre i storlek och levereras snabbare än JSON. MessagePack kanske dock inte förbättrar prestandan. Prestandan för Azure SignalR Service är inte känslig för protokoll eftersom den inte avkodar meddelandets nyttolast under vidarebefordran av meddelanden från klienter till servrar eller vice versa.
Hitta en korrekt SKU
Hur kan du utvärdera den inkommande/utgående kapaciteten eller hitta vilken nivå som är lämplig för ett specifikt användningsfall?
Anta att appservern är tillräckligt kraftfull och inte är flaskhalsen för prestanda. Kontrollera sedan den maximala inkommande och utgående bandbredden för varje nivå.
Snabbutvärdering
Anta följande standardinställningar för en snabb utvärdering:
- Transporttypen är WebSocket.
- Meddelandestorleken är 2 048 byte.
- Ett meddelande skickas var 1 sekund.
- Azure SignalR Service är i standardläge.
Varje nivå har sin egen maximala inkommande bandbredd och utgående bandbredd. En smidig användarupplevelse garanteras inte när den inkommande eller utgående anslutningen överskrider gränsen.
Echo ger den maximala inkommande bandbredden eftersom den har den lägsta routningskostnaden. Broadcast definierar den maximala utgående meddelandebandbredden.
Överskrid inte de markerade värdena i följande två tabeller.
| Echo | Enhet 1 | Enhet 2 | Enhet 10 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| Kontakter | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Inkommande bandbredd | 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 |
| Utgående bandbredd | 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 |
| Sändning | Enhet 1 | Enhet 2 | Enhet 10 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| Kontakter | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Inkommande bandbredd | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s |
| Utgående bandbredd | 4 Mbit/s | 8 Mbit/s | 40 Mbit/s | 200 Mbit/s | 400 Mbit/s | 800 Mbit/s | 2 000 Mbit/s | 4 000 Mbit/s |
Inkommande bandbredd och utgående bandbredd är den totala meddelandestorleken per sekund. Här är formlerna för dem:
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: Tiden för att skicka ett meddelande. Vanligtvis är det 1 sekund per meddelande, vilket innebär att skicka ett meddelande varje sekund. Ett mindre intervall innebär att fler meddelanden skickas under en tidsperiod. Till exempel innebär 0,5 sekund per meddelande att två meddelanden skickas varje sekund.
Anslut ions: Det incheckade maximala tröskelvärdet för Azure SignalR Service för varje nivå. Om anslutningsnumret ökar ytterligare drabbas det av anslutningsbegränsning.
Utvärdering för komplexa användningsfall
Större meddelandestorlek eller annan sändningsfrekvens
Det verkliga användningsfallet är mer komplicerat. Det kan skicka ett meddelande som är större än 2 048 byte, eller så är sändningsfrekvensen inte ett meddelande per sekund. Nu ska vi ta lektion 100-sändningen som ett exempel för att ta reda på hur du utvärderar dess prestanda.
I följande tabell visas ett verkligt användningsfall för sändning. Men meddelandestorleken, antalet anslutningar och sändningshastigheten för meddelanden skiljer sig från vad vi antog i föregående avsnitt. Frågan är hur vi kan härleda något av dessa objekt (meddelandestorlek, antal anslutningar eller sändningshastighet för meddelanden) om vi bara känner till två av dem.
| Sändning | Meddelandestorlek | Samtidiga inkommande meddelanden | Kontakter | Skicka intervall |
|---|---|---|---|---|
| 1 | 20 KB | 1 | 100,000 | 5 sek |
| 2 | 256 kB | 1 | 8,000 | 5 sek |
Följande formel är lätt att härleda baserat på den tidigare formeln:
outboundConnections = outboundBandwidth * sendInterval / messageSize
För enhet 100 är den maximala utgående bandbredden 400 MB från föregående tabell. För en meddelandestorlek på 20 KB ska den maximala utgående anslutningen vara 400 MB * 5/20 KB = 100 000, vilket matchar det verkliga värdet.
Blandade användningsfall
Det verkliga användningsfallet blandar vanligtvis de fyra grundläggande användningsfallen: eko, sändning, skicka till grupp och skicka till anslutning. Den metod som du använder för att utvärdera kapaciteten är att:
- Dela upp de blandade användningsfallen i fyra grundläggande användningsfall.
- Beräkna den maximala bandbredden för inkommande och utgående meddelanden med hjälp av föregående formler separat.
- Summera bandbreddsberäkningarna för att få den totala maximala inkommande/utgående bandbredden.
Hämta sedan rätt nivå från de maximala tabellerna för inkommande/utgående bandbredd.
Kommentar
För att skicka ett meddelande till hundratals eller tusentals små grupper, eller för tusentals klienter som skickar ett meddelande till varandra, blir routningskostnaden dominerande. Ta hänsyn till den här effekten.
Om du vill skicka ett meddelande till klienter kontrollerar du att appservern inte är flaskhalsen. Följande avsnitt "Fallstudie" innehåller riktlinjer för hur många appservrar du behöver och hur många serveranslutningar du ska konfigurera.
Fallstudie
Följande avsnitt går igenom fyra vanliga användningsfall för WebSocket-transport: eko, sändning, skicka till grupp och skicka till anslutning. För varje scenario listar avsnittet den aktuella inkommande och utgående kapaciteten för Azure SignalR Service. Det förklarar också de viktigaste faktorerna som påverkar prestanda.
I standardläget skapar appservern fem serveranslutningar med Azure SignalR Service. Appservern använder Azure SignalR Service SDK som standard. I följande prestandatestresultat ökas serveranslutningarna till 15 (eller mer för sändning och sändning av ett meddelande till en stor grupp).
Olika användningsfall har olika krav för appservrar. Sändningen behöver ett litet antal appservrar. Eko eller skicka till anslutning behöver många appservrar.
I alla användningsfall är standardstorleken för meddelandet 2 048 byte och intervallet för meddelandesändning är 1 sekund.
Standardläge
Klienter, webbappservrar och Azure SignalR Service är inblandade i standardläget. Varje klient står för en enda anslutning.
Echo
Först ansluter en webbapp till Azure SignalR Service. För det andra ansluter många klienter till webbappen, som omdirigerar klienterna till Azure SignalR Service med åtkomsttoken och slutpunkten. Sedan upprättar klienterna WebSocket-anslutningar med Azure SignalR Service.
När alla klienter har upprättat anslutningar börjar de skicka ett meddelande som innehåller en tidsstämpel till den specifika hubben varje sekund. Hubben ekar tillbaka meddelandet till sin ursprungliga klient. Varje klient beräknar svarstiden när den tar emot ekomeddelandet tillbaka.
I följande diagram finns 5 till 8 (rödmarkerad trafik) i en loop. Loopen körs under en standardvaraktighet (5 minuter) och hämtar statistiken över alla svarstider för meddelanden.
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 |
|---|---|---|---|---|---|---|---|---|
| Kontakter | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Inkommande/utgående meddelanden per sekund | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Inkommande/utgående bandbredd | 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 |
I det här användningsfallet anropar varje klient den hubb som definierats på appservern. Hubben anropar bara den metod som definierats på den ursprungliga klientsidan. Den här hubben är den enklaste hubben för eko.
public void Echo(IDictionary<string, object> data)
{
Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
}
Även för den här enkla hubben är trafikbelastningen på appservern framträdande när ekobelastningen för inkommande meddelanden ökar. Det här trafiktrycket kräver många appservrar för stora SKU-nivåer. I följande tabell visas antalet appservrar för varje nivå.
| Echo | Enhet 1 | Enhet 2 | Enhet 10 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| Kontakter | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Antal appservrar | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Kommentar
Klientanslutningsnumret, meddelandestorleken, meddelandesändningshastigheten, SKU-nivån och processorn/minnet för appservern påverkar ekots övergripande prestanda.
Sändning
För sändning, när webbappen tar emot meddelandet, sänder den till alla klienter. Ju fler klienter som ska sändas, desto mer meddelandetrafik finns det till alla klienter. Se följande diagram.
Ett litet antal klienter sänder. Bandbredden för inkommande meddelanden är liten, men den utgående bandbredden är enorm. Bandbredden för utgående meddelanden ökar när klientanslutningen eller sändningshastigheten ökar.
I följande tabell sammanfattas maximalt antal klientanslutningar, antal inkommande/utgående meddelanden och bandbredd.
| Sändning | Enhet 1 | Enhet 2 | Enhet 10 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| Kontakter | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Inkommande meddelanden per sekund | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Utgående meddelanden per sekund | 2 000 | 4 000 | 20 000 | 100,000 | 200 000 | 400,000 | 1 000 000 | 2,000,000 |
| Inkommande bandbredd | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s |
| Utgående bandbredd | 4 Mbit/s | 8 Mbit/s | 40 Mbit/s | 200 Mbit/s | 400 Mbit/s | 800 Mbit/s | 2 000 Mbit/s | 4 000 Mbit/s |
De sändningsklienter som publicerar meddelanden är högst fyra. De behöver färre appservrar jämfört med eko eftersom mängden inkommande meddelanden är liten. Två appservrar räcker för både serviceavtal och prestandaöverväganden. Men du bör öka standardserveranslutningarna för att undvika obalans, särskilt för enhet större än 50.
| Sändning | Enhet 1 | Enhet 2 | Enhet 10 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| Kontakter | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Antal appservrar | 1 | 1 | 1 | 2 | 2 | 4 | 10 | 20 |
Kommentar
Öka standardserveranslutningarna från 5 till 40 på varje appserver för att undvika eventuella obalanserade serveranslutningar till Azure SignalR Service.
Klientens anslutningsnummer, meddelandestorlek, meddelandesändningshastighet och SKU-nivå påverkar den övergripande prestandan för sändning.
Skicka till grupp
Användningsfallet skicka till grupp har ett liknande trafikmönster att sända. Skillnaden är att när klienter har upprättat WebSocket-anslutningar med Azure SignalR Service måste de ansluta grupper innan de kan skicka ett meddelande till en viss grupp. Följande diagram illustrerar trafikflödet.
Gruppmedlems- och gruppantal är två faktorer som påverkar prestanda. För att förenkla analysen definierar vi två typer av grupper:
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.
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.
Skicka till grupp medför en routningskostnad till Azure SignalR Service eftersom den måste hitta målanslutningarna via en distribuerad datastruktur. I takt med att de sändande anslutningarna ökar ökar kostnaden.
Liten grupp
Routningskostnaden är betydande för att skicka meddelanden till många små grupper. För närvarande når Azure SignalR Service-implementeringen gränsen för routningskostnad 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. Kontakta kundsupporten om du behöver mer inkommande bandbredd.
| Skicka till liten grupp | Enhet 1 | Enhet 2 | Enhet 10 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| Kontakter | 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 Mbit/s | 200 Mbit/s | 400 Mbit/s | 1 000 Mbit/s | 2 000 Mbit/s |
Många klientanslutningar anropar hubben, så appservernumret är också viktigt för prestanda. I följande tabell visas de föreslagna appserverantalen.
| Skicka till liten grupp | Enhet 1 | Enhet 2 | Enhet 10 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| Kontakter | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Antal appservrar | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Kommentar
Klientanslutningsnumret, meddelandestorleken, meddelandesändningshastigheten, routningskostnaden, SKU-nivån och processorn/minnet för appservern påverkar den övergripande prestandan för att skicka till en liten grupp.
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. Det är till exempel OK att tilldela varje conneciton till en distinkt grupp. Under den här konfigurationen är prestandan nära att skickas till anslutningen.
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, vilket är nästan detsamma som för sändning.
| Skicka till stor grupp | Enhet 1 | Enhet 2 | Enhet 10 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| Kontakter | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Antal gruppmedlemmar | 100 | 200 | 500 | 1 000 | 2 000 | 5 000 | 10,000 | 20 000 |
| Antal grupper | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Inkommande meddelanden per sekund | 20 | 20 | 20 | 20 | 20 | 20 | 20 | 20 |
| Inkommande bandbredd | 40 KBIT/s | 40 KBIT/s | 40 KBIT/s | 40 KBIT/s | 40 KBIT/s | 40 KBIT/s | 40 KBIT/s | 40 KBIT/s |
| Utgående meddelanden per sekund | 2 000 | 4 000 | 20 000 | 100,000 | 200 000 | 400,000 | 1 000 000 | 2,000,000 |
| Utgående bandbredd | 4 Mbit/s | 8 Mbit/s | 40 Mbit/s | 200 Mbit/s | 400 Mbit/s | 800 Mbit/s | 2 000 Mbit/s | 4 000 Mbit/s |
Antalet avsändaranslutningar är högst 40. Belastningen på appservern är liten, så det föreslagna antalet webbappar är litet.
| Skicka till stor grupp | Enhet 1 | Enhet 2 | Enhet 10 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| Kontakter | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Antal appservrar | 1 | 1 | 2 | 2 | 2 | 4 | 10 | 20 |
Kommentar
Öka standardserveranslutningarna från 5 till 40 på varje appserver för att undvika eventuella obalanserade serveranslutningar till Azure SignalR Service.
Klientanslutningsnumret, meddelandestorleken, meddelandesändningshastigheten, routningskostnaden och SKU-nivån påverkar den övergripande prestandan för att skicka till stor grupp.
Skicka till anslutning
När klienter upprättar anslutningar till Azure SignalR Service anropar varje klient en särskild hubb för att hämta sitt eget anslutnings-ID i fallet Skicka till anslutning. Prestandamåttet samlar in alla anslutnings-ID:er, blandar dem och omtilldelar dem till alla klienter som ett sändningsmål. Klienterna skickar meddelandet till målanslutningen tills prestandatestet är klart.
Routningskostnaden för att skicka till anslutningen liknar kostnaden för att skicka till en liten grupp.
När antalet anslutningar ökar blir routningskostnaden en kritisk faktor som begränsar den totala prestandan. I synnerhet markerar enhet 20 tröskelvärdet där tjänsten når routningsflaskhalsen. Ytterligare ökningar av antalet enheter ger inte prestandaförbättringar om det inte sker en övergång till Premium_P2(enhet >=100), vilket förbättrar routningsfunktionerna.
Följande tabell är en statistisk sammanfattning efter många omgångar av körning av referensvärdet skicka till anslutning .
| Skicka till anslutning | Enhet 1 | Enhet 2 | Enhet 20 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| Kontakter | 1 000 | 2 000 | 20 000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Inkommande/utgående meddelanden per sekund | 1 000 | 2 000 | 20 000 | 20 000 | 20 000 | 40,000 | 100,000 | 200 000 |
| Inkommande/utgående bandbredd | 2 Mbit/s | 4 Mbit/s | 40 Mbit/s | 40 Mbit/s | 40 Mbit/s | 80 Mbit/s | 200 Mbit/s | 400 Mbit/s |
Kommentar
Trots stagnationen i inkommande/utgående meddelanden per sekund efter enhet 20 fortsätter kapaciteten för fler anslutningar att växa. I verkliga affärsscenarier är det ofta antalet anslutningar, inte deras samtidiga meddelandesändningsaktivitet, som utgör flaskhalsen. Det är ovanligt att alla anslutningar aktivt skickar meddelanden med så höga frekvenser som benchmark-testet gör.
Det här användningsfallet kräver hög belastning på appserversidan. Se det föreslagna antalet appservrar i följande tabell.
| Skicka till anslutning | Enhet 1 | Enhet 2 | Enhet 10 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| Kontakter | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Antal appservrar | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Kommentar
Klientanslutningsnumret, meddelandestorleken, sändningshastigheten för meddelanden, routningskostnaden, SKU-nivån och processorn/minnet för appservern påverkar den övergripande prestandan för att skicka till anslutningen.
ASP.NET SignalR
Azure SignalR Service har samma prestandakapacitet för ASP.NET SignalR.
Serverlöst läge
Klienter och Azure SignalR Service är inblandade i serverlöst läge. Varje klient står för en enda anslutning. Klienten skickar meddelanden via REST-API:et till en annan klient eller sänder meddelanden till alla.
Att skicka meddelanden med hög densitet via REST-API:et är inte lika effektivt som att använda WebSocket. Det kräver att du skapar en ny HTTP-anslutning varje gång, och det är en extra kostnad i serverlöst läge.
Sända via REST API
Alla klienter upprättar WebSocket-anslutningar med Azure SignalR Service. Sedan börjar vissa klienter att sända via REST-API:et. Meddelandet som skickar (inkommande) sker via HTTP Post, vilket inte är effektivt jämfört med WebSocket.
| Sända via REST API | Enhet 1 | Enhet 2 | Enhet 10 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| Kontakter | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Inkommande meddelanden per sekund | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Utgående meddelanden per sekund | 2 000 | 4 000 | 20 000 | 100,000 | 200 000 | 400,000 | 1 000 000 | 2,000,000 |
| Inkommande bandbredd | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s | 4 KBIT/s |
| Utgående bandbredd | 4 Mbit/s | 8 Mbit/s | 40 Mbit/s | 200 Mbit/s | 400 Mbit/s | 800 Mbit/s | 2 000 Mbit/s | 4 000 Mbit/s |
Skicka till användare via REST API
Benchmark tilldelar användarnamn till alla klienter innan de börjar ansluta till Azure SignalR Service. När klienterna har upprättat WebSocket-anslutningar med Azure SignalR Service börjar de skicka meddelanden till andra via HTTP Post.
| Skicka till användare via REST API | Enhet 1 | Enhet 2 | Enhet 10 | Enhet 50 | Enhet 100 | Enhet 200 | Enhet 500 | Enhet 1000 |
|---|---|---|---|---|---|---|---|---|
| Kontakter | 1 000 | 2 000 | 10,000 | 50,000 | 100,000 | 200 000 | 500,000 | 1 000 000 |
| Inkommande/utgående meddelanden per sekund | 200 | 400 | 2 000 | 10,000 | 20 000 | 40,000 | 100,000 | 200 000 |
| Inkommande/utgående bandbredd | 400 Kbit/s | 800 Kbit/s | 4 Mbit/s | 20 Mbit/s | 40 Mbit/s | 80 Mbit/s | 200 Mbit/s | 400 Mbit/s |
Prestandatestmiljöer
För alla användningsfall som anges ovan genomförde vi prestandatesterna i en Azure-miljö. Som mest använde vi 200 virtuella klientdatorer och 100 virtuella appserverdatorer. Här följer några detaljer:
Storlek på virtuell klientdator: StandardDS2V2 (2 vCPU, 7G-minne)
Storlek på den virtuella appserverdatorn: StandardF4sV2 (4 vCPU, 8G-minne)
Azure SignalR SDK-serveranslutningar: 15
Prestandaverktyg
Du hittar prestandaverktyg för Azure SignalR Service på GitHub.
Nästa steg
I den här artikeln får du en översikt över Prestanda för Azure SignalR Service i vanliga användningsfall.
Information om tjänstens interna funktioner och skalning finns i följande guider: