Prestatierichtlijnen voor Azure SignalR Service
Een van de belangrijkste voordelen van het gebruik van Azure SignalR Service is het gemak van het schalen van SignalR-toepassingen. In een grootschalig scenario is de prestaties een belangrijke factor.
In dit artikel wordt het volgende beschreven:
- De factoren die van invloed zijn op de prestaties van SignalR-toepassingen.
- De typische prestaties in verschillende use-casescenario's.
- De omgeving en hulpprogramma's die u kunt gebruiken om een prestatierapport te genereren.
Snelle evaluatie met metrische gegevens
U kunt uw service eenvoudig bewaken in Azure Portal. Op de pagina Metrische gegevens van uw SignalR-exemplaar kunt u de metrische gegevens voor serverbelasting selecteren om de 'druk' van uw service te zien.
In de grafiek ziet u de rekendruk van uw SignalR-service. U kunt uw scenario testen en deze metrische waarde controleren om te bepalen of u omhoog wilt schalen. De latentie binnen SignalR-service blijft laag als de serverbelasting lager is dan 70%.
Notitie
Als u eenheid 50 of groter gebruikt en uw scenario voornamelijk wordt verzonden naar kleine groepen (groepsgrootte <20) of één verbinding, moet u het verzenden naar een kleine groep controleren of naar een verbinding wordt verzonden ter referentie. In deze scenario's zijn er grote routeringskosten die niet zijn opgenomen in de serverbelasting.
Termendefinities
Binnenkomend: het binnenkomende bericht naar Azure SignalR Service.
Uitgaand: het uitgaande bericht van Azure SignalR Service.
Bandbreedte: de totale grootte van alle berichten in 1 seconde.
Standaardmodus: de standaardwerkmodus wanneer een Azure SignalR Service-exemplaar wordt gemaakt. Azure SignalR Service verwacht dat de app-server een verbinding tot stand brengt voordat er een clientverbinding wordt geaccepteerd.
Serverloze modus: een modus waarin Azure SignalR Service alleen clientverbindingen accepteert. Er is geen serververbinding toegestaan.
Overzicht
Azure SignalR Service definieert zeven Standard-lagen voor verschillende prestatiecapaciteiten. In deze handleiding worden de volgende vragen beantwoord:
Wat zijn de typische prestaties van de Azure SignalR-service voor elke laag (eenheid)?
Voldoet Azure SignalR Service aan mijn vereisten voor berichtdoorvoer (bijvoorbeeld 100.000 berichten per seconde verzenden)?
Hoe kan ik voor mijn specifieke scenario de juiste laag selecteren?
Wat voor soort app-server (VM-grootte) is geschikt voor mij? Hoeveel daarvan moet ik implementeren?
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 elke laag voor typische gebruiksvoorbeelden: echo, uitzending, verzenden naar groep en verzenden naar verbinding (peer-to-peer-chatten).
Deze handleiding kan niet alle scenario's behandelen (en verschillende use cases, berichtgrootten, bericht verzendende patronen, enzovoort). Maar het biedt enkele methoden om u te helpen:
- Evalueer uw geschatte vereiste voor de inkomende of uitgaande berichten.
- Zoek de juiste lagen door de prestatietabel te controleren.
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. Voor Azure SignalR Service heeft elke SKU-laag een eigen doorvoerbeperkingsbeleid. Het beleid definieert de maximaal toegestane doorvoer (binnenkomende en uitgaande bandbreedte) als de maximale bereikte doorvoer wanneer 99 procent van de berichten latentie heeft die kleiner is dan 1 seconde.
Latentie is de tijdsduur van de verbinding die het bericht verzendt naar het ontvangen van het antwoordbericht van Azure SignalR Service. Neem echo als voorbeeld. Elke clientverbinding voegt een tijdstempel toe aan het bericht. De hub van de app-server verzendt het oorspronkelijke bericht terug naar de client. De doorgiftevertraging wordt dus eenvoudig berekend door elke clientverbinding. Het tijdstempel wordt toegevoegd voor elk bericht in uitzending, verzenden naar groep en verzenden naar verbinding.
Als u duizenden gelijktijdige clientverbindingen wilt simuleren, worden er meerdere VM's gemaakt in een virtueel particulier netwerk in Azure. Al deze VM's maken verbinding met hetzelfde Exemplaar van Azure SignalR Service.
In de standaardmodus van Azure SignalR Service worden app-server-VM's geïmplementeerd in hetzelfde virtuele particuliere netwerk als client-VM's. Alle client-VM's en app-server-VM's worden geïmplementeerd in hetzelfde netwerk van dezelfde regio om latentie tussen regio's te voorkomen.
Prestatiefactoren
De volgende factoren zijn van invloed op de prestaties van SignalR.
- SKU-laag (CPU/geheugen)
- Aantal verbindingen
- Berichtgrootte
- Verzendsnelheid van bericht
- Transporttype (WebSocket, Server-Sent-Event of Long-Polling)
- Use-casescenario (routeringskosten)
- App-server- en serviceverbindingen (in servermodus)
Computerbronnen
Theoretisch wordt azure SignalR Service-capaciteit beperkt door rekenresources: CPU, geheugen en netwerk. Meer verbindingen met Azure SignalR 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 SignalR Service meer CPU-cycli uitgeven om verkeer te verwerken. Ondertussen legt Azure-netwerkbandbreedte ook een limiet op voor maximaal verkeer.
Transporttype
Het transporttype is een andere factor die van invloed is op de prestaties. De drie typen zijn:
- WebSocket: WebSocket is een bidirectioneel en full-duplex communicatieprotocol via één TCP-verbinding.
- Server-Sent-Event: Server-Sent-Event is een unidirectioneel protocol om berichten van server naar client te pushen.
- Long-Polling: Voor long-polling moeten de clients periodiek informatie van de server peilen via een HTTP-aanvraag.
Voor dezelfde API onder dezelfde omstandigheden heeft WebSocket de beste prestaties, Server-Sent-Event langzamer en is Long-Polling de traagste. Azure SignalR Service raadt WebSocket standaard aan.
Kosten voor berichtroutering
De kosten voor berichtroutering beperkt ook de prestaties. Azure SignalR Service speelt een rol als een berichtrouter, waarmee het bericht wordt gerouteerd van een set clients of servers naar andere clients of servers. Voor een ander scenario of EEN ANDERE API is een ander routeringsbeleid vereist.
Voor echo verzendt de client een bericht naar zichzelf en is de routeringsbestemming ook zelf. Dit patroon heeft de laagste routeringskosten. Maar voor uitzending, verzenden naar groep en verzenden naar verbinding moet Azure SignalR 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.
In de standaardmodus kan de app-server ook een knelpunt worden voor bepaalde scenario's. De Azure SignalR SDK moet de hub aanroepen, terwijl er een liveverbinding met elke client wordt onderhouden via heartbeatsignalen.
In de serverloze modus verzendt de client een bericht per HTTP-bericht, wat niet zo efficiënt is als WebSocket.
Protocol
Een andere factor is protocol: JSON en MessagePack. MessagePack is kleiner en sneller geleverd dan JSON. MessagePack verbetert mogelijk de prestaties echter niet. De prestaties van Azure SignalR Service zijn niet gevoelig voor protocollen omdat de nettolading van het bericht niet wordt gedecodeerd tijdens het doorsturen van berichten van clients naar servers of omgekeerd.
Een juiste SKU zoeken
Hoe kunt u de binnenkomende/uitgaande capaciteit evalueren of bepalen welke laag geschikt is voor een specifieke use-case?
Stel dat de app-server krachtig genoeg is en niet het prestatieknelpunt is. Controleer vervolgens de maximale binnenkomende en uitgaande bandbreedte voor elke laag.
Snelle evaluatie
Voor een snelle evaluatie gaat u uit van de volgende standaardinstellingen:
- Het transporttype is WebSocket.
- De berichtgrootte is 2048 bytes.
- Er wordt elke 1 seconde een bericht verzonden.
- Azure SignalR Service bevindt zich in de standaardmodus.
Elke laag heeft een eigen maximale binnenkomende bandbreedte en uitgaande bandbreedte. Een soepele gebruikerservaring wordt niet gegarandeerd nadat de binnenkomende of uitgaande verbinding de limiet overschrijdt.
Echo geeft de maximale binnenkomende bandbreedte omdat deze de laagste routeringskosten heeft. Broadcast definieert de maximale bandbreedte voor uitgaande berichten.
De gemarkeerde waarden in de volgende twee tabellen niet overschrijden.
| 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 |
| Binnenkomende bandbreedte | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1000 MBps | 2000 MBps |
| Uitgaande bandbreedte | 2 Mbps | 4 Mbps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1000 MBps | 2000 MBps |
| Uitzenden | 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 bandbreedte | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Uitgaande bandbreedte | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2000 MBps | 4.000 MBps |
Binnenkomende bandbreedte en uitgaande bandbreedte zijn de totale berichtgrootte per seconde. Dit zijn de formules voor deze formules:
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 tijdstip waarop één bericht wordt verzonden. Meestal is het 1 seconde per bericht, wat betekent 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 per bericht betekent bijvoorbeeld dat er elke seconde twee berichten worden verzonden.
Verbinding maken ions: de vastgelegde maximumdrempel voor Azure SignalR Service voor elke laag. Als het verbindingsnummer verder wordt verhoogd, heeft dit last van verbindingsbeperking.
Notitie
U moet omhoog schalen naar SKU-Premium_P2 om een eenheidsgrootte van meer dan 100 te hebben.
Evaluatie voor complexe use cases
Grotere berichtgrootte of een andere verzendsnelheid
De echte use case is ingewikkelder. Het kan een bericht verzenden dat groter is dan 2048 bytes of dat de snelheid van het verzenden van berichten niet per seconde is. Laten we de uitzending van Unit 100 als voorbeeld nemen om te ontdekken hoe de prestaties ervan kunnen worden geëvalueerd.
In de volgende tabel ziet u een echte use-case van broadcast. Maar de berichtgrootte, het aantal verbindingen en de verzendsnelheid van berichten verschillen van wat we in de vorige sectie hebben aangenomen. De vraag is hoe we een van deze items kunnen afleiden (berichtgrootte, aantal verbindingen of verzendsnelheid van berichten) als we er slechts twee kennen.
| Uitzenden | Berichtgrootte | Gelijktijdige binnenkomende berichten | Connecties | Intervallen verzenden |
|---|---|---|---|---|
| 1 | 20 KB | 1 | 100.000 | 5 sec |
| 2 | 256 kB | 1 | 8,000 | 5 sec |
De volgende formule is eenvoudig af te stellen op basis van de vorige formule:
outboundConnections = outboundBandwidth * sendInterval / messageSize
Voor eenheid 100 is de maximale uitgaande bandbreedte 400 MB uit de vorige tabel. Voor een berichtgrootte van 20 kB moet de maximale uitgaande verbindingen 400 MB * 5 /20 kB = 100.000 zijn, die overeenkomt met de werkelijke waarde.
Gemengde gebruiksvoorbeelden
De echte use case combineert doorgaans de vier basisgebruiksvoorbeelden: echo, uitzending, verzenden naar groep en verzenden naar verbinding. De methodologie die u gebruikt om de capaciteit te evalueren, is het volgende:
- Verdeel de gemengde use cases in vier basisgebruiksvoorbeelden.
- Bereken de maximale bandbreedte voor inkomend en uitgaand bericht met behulp van de voorgaande formules afzonderlijk.
- Som de bandbreedteberekeningen op om de totale maximale binnenkomende/uitgaande bandbreedte op te halen.
Haal vervolgens de juiste laag op uit de tabellen met maximale binnenkomende/uitgaande bandbreedte.
Notitie
Voor het verzenden van een bericht naar honderden of duizenden kleine groepen, of voor duizenden clients die een bericht naar elkaar verzenden, worden de routeringskosten dominant. Neem rekening met dit effect.
Voor het gebruik van een bericht naar clients moet u ervoor zorgen dat de app-server niet het knelpunt is. De volgende sectie 'Casestudy' bevat richtlijnen voor het aantal app-servers dat u nodig hebt en hoeveel serververbindingen u moet configureren.
Casestudy
In de volgende secties worden vier typische gebruiksvoorbeelden voor WebSocket-transport doorlopen: echo, uitzending, verzenden naar groep en verzenden naar verbinding. Voor elk scenario bevat de sectie de huidige binnenkomende en uitgaande capaciteit voor Azure SignalR Service. Ook worden de belangrijkste factoren uitgelegd die van invloed zijn op de prestaties.
In de standaardmodus maakt de app-server vijf serververbindingen met Azure SignalR Service. De app-server maakt standaard gebruik van de Azure SignalR Service SDK. In de volgende resultaten van de prestatietest worden serververbindingen verhoogd tot 15 (of meer voor het uitzenden en verzenden van een bericht naar een grote groep).
Verschillende use cases hebben verschillende vereisten voor app-servers. Broadcast heeft een klein aantal app-servers nodig. Echo of verzenden naar verbinding vereist veel app-servers.
In alle gebruiksscenario's is de standaard berichtgrootte 2048 bytes en is het verzendinterval van het bericht 1 seconde.
Standaardmodus
Clients, web-app-servers en Azure SignalR Service zijn betrokken bij de standaardmodus. Elke client staat voor één verbinding.
Echo
Eerst maakt een web-app verbinding met Azure SignalR Service. Ten tweede maken veel clients verbinding met de web-app, waarmee de clients worden omgeleid naar Azure SignalR Service met het toegangstoken en eindpunt. Vervolgens maken de clients WebSocket-verbindingen met Azure SignalR Service.
Nadat alle clients verbindingen tot stand hebben gebracht, beginnen ze elke seconde een bericht met een tijdstempel naar de specifieke hub te verzenden. De hub echot het bericht terug naar de oorspronkelijke client. Elke client berekent de latentie wanneer deze het echobericht terug ontvangt.
In het volgende diagram bevinden 5 tot en met 8 (rood gemarkeerd verkeer) zich in een lus. De lus wordt uitgevoerd voor een standaardduur (5 minuten) en haalt de statistiek van alle berichtlatentie op.
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 | 1.000 | 2.000 | 10,000 | 50,000 | 100.000 | 200.000 | 500,000 | 1.000.000 |
| Binnenkomende/uitgaande bandbreedte | 2 Mbps | 4 Mbps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1000 MBps | 2000 MBps |
In dit gebruiksscenario roept elke client de hub aan die is gedefinieerd in de app-server. De hub roept alleen de methode aan die is gedefinieerd in de oorspronkelijke clientzijde. Deze hub is de meest lichtgewicht hub voor echo.
public void Echo(IDictionary<string, object> data)
{
Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
}
Zelfs voor deze eenvoudige hub is de verkeersdruk op de app-server prominent, omdat de belasting van het echo-inkomende bericht toeneemt. Deze verkeersdruk vereist veel app-servers voor grote SKU-lagen. De volgende tabel bevat het aantal app-servers voor elke laag.
| 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 |
| Aantal app-servers | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Notitie
Het clientverbindingsnummer, de berichtgrootte, de verzendsnelheid van berichten, de SKU-laag en het CPU/geheugen van de app-server zijn van invloed op de algehele prestaties van echo.
Uitzenden
Wanneer de web-app het bericht ontvangt, wordt het voor uitzending uitgezonden naar alle clients. Hoe meer clients er zijn om uit te zenden, hoe meer berichtenverkeer er is voor alle clients. Zie het volgende diagram.
Een klein aantal clients wordt uitgezonden. De bandbreedte voor binnenkomende berichten is klein, maar de uitgaande bandbreedte is enorm. De bandbreedte voor uitgaande berichten neemt toe naarmate de clientverbinding of broadcastsnelheid toeneemt.
De volgende tabel bevat een overzicht van de maximale clientverbindingen, het aantal inkomende/uitgaande berichten en de bandbreedte.
| Uitzenden | 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 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Uitgaande berichten per seconde | 2.000 | 4000 | 20,000 | 100.000 | 200.000 | 400,000 | 1.000.000 | 2,000,000 |
| Binnenkomende bandbreedte | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Uitgaande bandbreedte | 4 Mbps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2000 MBps | 4.000 MBps |
De uitzendclients die berichten posten, zijn niet meer dan vier. Ze hebben minder app-servers nodig in vergelijking met echo omdat de hoeveelheid inkomende berichten klein is. Twee app-servers zijn voldoende voor zowel SLA- als prestatieoverwegingen. Maar u moet de standaardserververbindingen verhogen om onevenwichtigheid te voorkomen, met name voor eenheid groter dan 50.
| Uitzenden | 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 app-servers | 1 | 1 | 1 | 2 | 2 | 4 | 10 | 20 |
Notitie
Verhoog de standaardserververbindingen van 5 tot 40 op elke app-server om mogelijke niet-verdeelde serververbindingen met Azure SignalR Service te voorkomen.
Het verbindingsnummer van de client, de berichtgrootte, de verzendsnelheid van berichten en de SKU-laag zijn van invloed op de algehele prestaties voor broadcast.
Verzenden naar groep
De use-case verzenden naar groep heeft een vergelijkbaar verkeerspatroon voor broadcast. Het verschil is dat nadat clients WebSocket-verbindingen met Azure SignalR Service tot stand hebben gebracht, ze moeten deelnemen aan groepen voordat ze een bericht kunnen verzenden naar een specifieke groep. In het volgende diagram ziet u de verkeersstroom.
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:
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.
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.
Verzenden naar groep brengt routeringskosten naar Azure SignalR Service omdat deze de doelverbindingen moet vinden via een gedistribueerde gegevensstructuur. Naarmate de verzendende verbindingen toenemen, neemt de kosten toe.
Kleine groep
De routeringskosten zijn aanzienlijk voor het verzenden van berichten naar veel kleine groepen. Momenteel raakt de implementatie van de Azure SignalR-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. Neem contact op met de klantondersteuning als u meer binnenkomende bandbreedte nodig hebt.
| 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 |
Veel clientverbindingen roepen de hub aan, dus het app-servernummer is ook essentieel voor prestaties. De volgende tabel bevat het aantal voorgestelde app-servers.
| 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 app-servers | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Notitie
Het verbindingsnummer van de client, de berichtgrootte, de verzendsnelheid van berichten, de routeringskosten, de SKU-laag en het CPU/geheugen van de app-server zijn van invloed op de algehele prestaties van verzenden naar kleine groepen.
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. Het is bijvoorbeeld OK om elke verbinding toe te wijzen aan een afzonderlijke groep. Onder deze configuratie zijn de prestaties dicht bij het verzenden naar de verbinding.
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, die bijna hetzelfde is als die voor broadcast.
| 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 | 500 | 1.000 | 2.000 | 5.000 | 10,000 | 20,000 |
| Aantal groepen | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Binnenkomende berichten per seconde | 20 | 20 | 20 | 20 | 20 | 20 | 20 | 20 |
| Binnenkomende bandbreedte | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps |
| Uitgaande berichten per seconde | 2.000 | 4000 | 20,000 | 100.000 | 200.000 | 400,000 | 1.000.000 | 2,000,000 |
| Uitgaande bandbreedte | 4 Mbps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2000 MBps | 4.000 MBps |
Het aantal verzonden verbindingen is niet meer dan 40. De belasting van de app-server is klein, dus het voorgestelde aantal web-apps is klein.
| 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 app-servers | 1 | 1 | 2 | 2 | 2 | 4 | 10 | 20 |
Notitie
Verhoog de standaardserververbindingen van 5 tot 40 op elke app-server om mogelijke niet-verdeelde serververbindingen met Azure SignalR Service te voorkomen.
Het verbindingsnummer van de client, de berichtgrootte, de verzendsnelheid van berichten, de routeringskosten en de SKU-laag zijn van invloed op de algehele prestaties van verzenden naar een grote groep.
Verzenden naar verbinding
Wanneer clients de verbindingen met Azure SignalR Service tot stand brengen, wordt in het use-case verzenden naar een verbinding een speciale hub aanroepen om hun eigen verbindings-id op te halen. De prestatiebenchmark verzamelt alle verbindings-id's, plaatst ze in willekeurige volgorde en wijs ze opnieuw toe aan alle clients als een verzendend doel. De clients blijven het bericht verzenden naar de doelverbinding totdat de prestatietest is voltooid.
De routeringskosten voor verzenden naar verbinding zijn vergelijkbaar met de kosten voor verzenden naar kleine groepen.
Naarmate het aantal verbindingen toeneemt, worden de routeringskosten een kritieke factor voor het beperken van de algehele prestaties. In eenheid 20 wordt met name de drempelwaarde gemarkeerd waarbij de service het knelpunt van de routering raakt. Verdere toename van het aantal eenheden levert geen prestatieverbeteringen op, tenzij er een verschuiving naar Premium_P2(eenheid >=100) is, waardoor routeringsmogelijkheden worden verbeterd.
De volgende tabel is een statistische samenvatting na veel rondes van het uitvoeren van de send to connection benchmark.
| Verzenden naar verbinding | Eenheid 1 | Eenheid 2 | Eenheid 20 | Eenheid 50 | Eenheid 100 | Eenheid 200 | Eenheid 500 | Eenheid 1000 |
|---|---|---|---|---|---|---|---|---|
| Connecties | 1.000 | 2.000 | 20,000 | 50,000 | 100.000 | 200.000 | 500,000 | 1.000.000 |
| Inkomende/uitgaande berichten per seconde | 1.000 | 2.000 | 20,000 | 20,000 | 20,000 | 40.000 | 100.000 | 200.000 |
| Binnenkomende/uitgaande bandbreedte | 2 Mbps | 4 Mbps | 40 MBps | 40 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
Notitie
Ondanks de stagnatie in inkomende/uitgaande berichten per seconde na eenheid 20 blijft de capaciteit voor meer verbindingen toenemen. In echte bedrijfsscenario's is het vaak het aantal verbindingen, niet de gelijktijdige activiteit voor het verzenden van berichten, die het knelpunt vormen. Het is ongebruikelijk dat alle verbindingen berichten actief met hoge frequenties verzenden, zoals de benchmarktest wel doet.
Voor deze use case is een hoge belasting aan de serverzijde van de app vereist. Zie het aantal voorgestelde app-servers in de volgende tabel.
| Verzenden naar verbinding | 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 app-servers | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Notitie
Het clientverbindingsnummer, de berichtgrootte, de verzendsnelheid van berichten, de routeringskosten, de SKU-laag en het CPU/geheugen voor de app-server zijn van invloed op de algehele prestaties van verzenden naar verbinding.
ASP.NET SignalR
Azure SignalR Service biedt dezelfde prestatiecapaciteit voor ASP.NET SignalR.
Serverloze modus
Clients en Azure SignalR Service zijn betrokken bij de serverloze modus. Elke client staat voor één verbinding. De client verzendt berichten via de REST API naar een andere client of broadcastberichten naar iedereen.
Het verzenden van high-densityberichten via de REST API is niet zo efficiënt als het gebruik van WebSocket. Hiervoor moet u elke keer een nieuwe HTTP-verbinding maken en dat zijn extra kosten in de serverloze modus.
Uitzenden via REST API
Alle clients maken WebSocket-verbindingen met Azure SignalR Service. Vervolgens beginnen sommige clients te uitzenden via de REST API. Het bericht dat wordt verzonden (inkomend) is allemaal via HTTP Post, wat niet efficiënt is vergeleken met WebSocket.
| 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 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Uitgaande berichten per seconde | 2.000 | 4000 | 20,000 | 100.000 | 200.000 | 400,000 | 1.000.000 | 2,000,000 |
| Binnenkomende bandbreedte | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Uitgaande bandbreedte | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2000 MBps | 4.000 MBps |
Verzenden naar gebruiker via REST API
De benchmark wijst gebruikersnamen toe aan alle clients voordat ze verbinding maken met Azure SignalR Service. Nadat de clients WebSocket-verbindingen met Azure SignalR Service tot stand hebben gebracht, beginnen ze berichten naar anderen te verzenden via HTTP Post.
| 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 | 200 | 400 | 2.000 | 10,000 | 20,000 | 40.000 | 100.000 | 200.000 |
| Binnenkomende/uitgaande bandbreedte | 400 KBps | 800 KBps | 4 Mbps | 20 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
Testomgevingen voor prestaties
Voor alle hierboven vermelde gebruiksvoorbeelden hebben we de prestatietests uitgevoerd in een Azure-omgeving. We hebben maximaal 200 client-VM's en 100 app-server-VM's gebruikt. Hier volgen enkele details:
Grootte van client-VM: StandardDS2V2 (2 vCPU, 7G-geheugen)
Vm-grootte van app-server: StandardF4sV2 (4 vCPU, 8G-geheugen)
Azure SignalR SDK-serververbindingen: 15
Hulpprogramma's voor prestaties
U vindt prestatiehulpprogramma's voor Azure SignalR Service op GitHub.
Volgende stappen
In dit artikel hebt u een overzicht gekregen van de prestaties van Azure SignalR Service in typische use-casescenario's.
Lees de volgende handleidingen voor meer informatie over de interne functies van de service en het schalen ervan: