Dela via

Meddelanden och anslutningar i Azure SignalR Service

  • Artikel

Faktureringsmodellen för Azure SignalR Service baseras på antalet anslutningar och antalet utgående meddelanden från tjänsten. I den här artikeln förklaras hur meddelanden och anslutningar definieras och räknas.

Meddelandeformat

Azure SignalR Service stöder samma format som ASP.NET Core SignalR: JSON och MessagePack.

Meddelandestorlek

Följande begränsningar gäller för Azure SignalR Service-meddelanden:

  • Klientmeddelanden:
    • För långa avsöknings- eller serverhändelser kan klienten inte skicka meddelanden som är större än 1 MB.
    • Det finns ingen storleksgräns för WebSocket för tjänsten.
    • Appservern kan ange en gräns för klientens meddelandestorlek. Standardvärdet är 32 KB. Mer information finns i Säkerhetsöverväganden i ASP.NET Core SignalR.
    • För serverlös begränsas meddelandestorleken av överordnad implementering, men under 1 MB rekommenderas.
  • Servermeddelanden:

För WebSocket-klienter delas stora meddelanden upp i mindre meddelanden som inte är mer än 2 KB vardera och överförs separat. SDK:er hanterar delning och sammansättning av meddelanden. Inget utvecklararbete krävs.

Stora meddelanden påverkar meddelandeprestanda negativt. Använd mindre meddelanden när det är möjligt och testa dig fram till den optimala meddelandestorleken för varje användningsfall.

Så beräknas meddelanden för fakturering

Meddelanden som skickas till tjänsten är inkommande meddelanden och meddelanden som skickas ut ur tjänsten är utgående meddelanden. Endast utgående meddelanden från Azure SignalR Service räknas för fakturering. Pingmeddelanden mellan klienter och servrar ignoreras.

Meddelanden som är större än 2 KB räknas som flera meddelanden på 2 KB vartdera. Diagrammet över antal meddelanden i Azure-portalen uppdateras vart 100:e meddelande för varje hubb.

Anta till exempel att du har en programserver och tre klienter:

  • När programservern sänder ett 1 KB-meddelande till alla anslutna klienter betraktas meddelandet från programservern till tjänsten som ett kostnadsfritt inkommande meddelande. De tre meddelanden som skickas från tjänsten till var och en av klienterna är utgående meddelanden och faktureras.

  • När klient A skickar ett inkommande meddelande på 1 KB till klient B, utan att gå via appservern, är meddelandet ett kostnadsfritt inkommande meddelande. Meddelandet som dirigeras från tjänsten till klient B faktureras som ett utgående meddelande.

  • Om du har tre klienter och en programserver är antalet fakturerade meddelanden åtta när en klient skickar ett 4 KB-meddelande för serversändningen till alla klienter:

    • Ett meddelande från tjänsten till programservern.
    • Tre meddelanden från tjänsten till klienterna. Varje meddelande räknas som två meddelanden på 2 KB vartdera.

Så räknas anslutningar

Azure SignalR Service skapar programserver- och klientanslutningar. Som standard börjar varje programserver med fem inledande anslutningar per hubb och varje klient har en klientanslutning.

Anta till exempel att du har två programservrar och att du definierar fem hubbar i kod. Antalet serveranslutningar är 50: (2 appservrar * 5 hubbar * 5 anslutningar per hubb).

Antalet anslutningar som visas i Azure-portalen omfattar anslutningar för server, klient, diagnostik och livespårning. Anslutningstyperna definieras i följande lista:

  • Serveranslutning: Anslut Azure SignalR Service och appservern.
  • Klientanslutning: Anslut Azure SignalR Service och klientappen.
  • Diagnostikanslutning: En särskild typ av klientanslutning som kan skapa en mer detaljerad logg, vilket kan påverka prestanda. Den här typen av klient är utformad för felsökning.
  • Livespårningsanslutning: Anslut till slutpunkten för livespårning och tar emot livespårningar av Azure SignalR Service.

En livespårningsanslutning räknas inte som en klientanslutning eller som en serveranslutning.

ASP.NET SignalR beräknar serveranslutningar på ett annat sätt. Det omfattar en standardhubb utöver de hubbar som du definierar. Som standard behöver varje programserver ytterligare fem inledande serveranslutningar. Det inledande antalet anslutningar för standardhubben förblir konsekvent med andra hubbar.

Tjänsten och programservern fortsätter att synkronisera anslutningsstatus och göra justeringar i serveranslutningar för att få bättre prestanda och tjänststabilitet. Så du kan se ändringar i antalet serveranslutningar i din tjänst som körs.