Delen via

ASP.NET Core SignalR hosten en schalen

Door Andrew Stanton-Nurse, Brady Gaster en Tom Dykstra

In dit artikel worden overwegingen voor hosting en schaalaanpassing uitgelegd voor apps met veel verkeer die gebruikmaken van ASP.NET Core SignalR.

Plaksessies

SignalR vereist dat alle HTTP-aanvragen voor een specifieke verbinding worden verwerkt door hetzelfde serverproces. Wanneer SignalR wordt uitgevoerd op een serverfarm (meerdere servers), moeten 'sticky sessions' worden gebruikt. "Sticky sessions" worden ook wel sessieaffiniteit genoemd. Azure App Service maakt gebruik van ARR (Application Request Routing) om aanvragen te routeren. Als u de instelling Sessieaffiniteit (ARR Affinity) inschakelt in uw Azure App Service, worden 'plaksessies' ingeschakeld. De enige omstandigheden waarin plaksessies niet vereist zijn voor de app zijn:

  1. Bij het hosten op één server in één proces.
  2. Wanneer u de Azure-service SignalR gebruikt (sticky sessions zijn ingeschakeld voor de service, niet voor de app).
  3. Wanneer alle clients zijn geconfigureerd om alleen WebSockets te gebruiken en de SkipNegotiation instelling is ingeschakeld in de clientconfiguratie.

In alle andere omstandigheden (inclusief wanneer het Redis-backplane wordt gebruikt), moet de serveromgeving worden geconfigureerd voor plaksessies.

Zie SignalR voor hulp bij het configureren van Azure App ServiceSignalR. Zie Blazorvoor hulp bij het configureren van plaksessies voor SignalR apps die gebruikmaken van de Blazor.

TCP-verbindingsbronnen

Het aantal gelijktijdige TCP-verbindingen dat een webserver kan ondersteunen, is beperkt. Standaard HTTP-clients maken gebruik van tijdelijke verbindingen. Deze verbindingen kunnen worden gesloten wanneer de client inactief gaat en later opnieuw wordt geopend. Aan de andere kant is een SignalR verbinding permanent. SignalR verbindingen blijven open, zelfs wanneer de client niet actief wordt. In een app met veel verkeer die veel clients bedient, kunnen deze permanente verbindingen ertoe leiden dat servers hun maximum aantal verbindingen bereiken.

Permanente verbindingen verbruiken ook wat extra geheugen om elke verbinding bij te houden.

Het intensief gebruik van verbindingsgerelateerde resources door SignalR kan invloed hebben op andere web-apps die op dezelfde server worden gehost. Wanneer SignalR deze wordt geopend en de laatst beschikbare TCP-verbindingen bevat, hebben andere web-apps op dezelfde server ook geen verbindingen meer.

Als een server geen verbindingen meer heeft, ziet u willekeurige socketfouten en fouten bij het opnieuw instellen van de verbinding. Voorbeeld:

An attempt was made to access a socket in a way forbidden by its access permissions...

Als u wilt voorkomen dat SignalR resourcegebruik fouten veroorzaakt in andere web-apps, voert u deze uit SignalR op verschillende servers dan uw andere web-apps.

Als u wilt voorkomen dat SignalR resourcegebruik fouten in een SignalR app veroorzaakt, schaalt u uit om het aantal verbindingen te beperken dat een server moet verwerken.

Horizontaal uitbreiden

Een app die gebruikmaakt SignalR , moet alle bijbehorende verbindingen bijhouden, waardoor er problemen ontstaan voor een serverfarm. Voeg een server toe en er worden nieuwe verbindingen weergegeven die de andere servers niet kennen. Op elke server in het volgende diagram is bijvoorbeeld SignalR niet bekend met de verbindingen op de andere servers. Wanneer SignalR op een van de servers een bericht naar alle clients wil verzenden, gaat het bericht alleen naar de clients die met die server zijn verbonden.

Schaalvergroting SignalR zonder backplane

De opties voor het oplossen van dit probleem zijn de Azure-service SignalR en redis-backplane.

Azure SignalR Dienst

De Azure-service SignalR fungeert als een proxy voor realtime verkeer en verdubbelt als een backplane wanneer de app wordt uitgeschaald op meerdere servers. Telkens wanneer een client een verbinding met de server initieert, wordt de client omgeleid om verbinding te maken met de service. Het proces wordt geïllustreerd door het volgende diagram:

Verbinding maken met de Azure-service SignalR

Het resultaat is dat de service alle clientverbindingen beheert, terwijl elke server slechts een klein constant aantal verbindingen met de service nodig heeft, zoals wordt weergegeven in het volgende diagram:

Clients die zijn verbonden met de service, servers die zijn verbonden met de service

Deze benadering voor uitschalen heeft verschillende voordelen ten opzichte van het redis-backplane-alternatief:

  • Plaksessies, ook wel clientaffiniteit genoemd, zijn niet vereist, omdat klanten onmiddellijk worden omgeleid naar de Azure-service SignalR wanneer ze verbinding maken.
  • Een SignalR app kan worden uitgeschaald op basis van het aantal verzonden berichten, terwijl de Azure SignalR Service wordt geschaald om een willekeurig aantal verbindingen af te handelen. Er kunnen bijvoorbeeld duizenden clients zijn, maar als er slechts een paar berichten per seconde worden verzonden, hoeft de SignalR app niet uit te schalen naar meerdere servers om de verbindingen zelf te verwerken.
  • Een SignalR app gebruikt niet aanzienlijk meer verbindingsresources dan een web-app zonder SignalR.

Daarom raden we de Azure-service SignalR aan voor alle ASP.NET Core-apps SignalR die worden gehost in Azure, waaronder App Service, VM's en containers.

Zie de documentatie van de Azure-service SignalRvoor meer informatie.

Redis-achtergrondnetwerk

Redis is een sleutel-waardearchief in het geheugen dat ondersteuning biedt voor een berichtensysteem met een publicatie-/abonneermodel. De SignalR Redis-backplane maakt gebruik van de pub-/subfunctie om berichten door te sturen naar andere servers. Wanneer een client een verbinding maakt, worden de verbindingsgegevens doorgegeven aan het backplane. Wanneer een server een bericht naar alle clients wil verzenden, wordt het naar het backplane verzonden. De backplane kent alle verbonden clients en op welke servers ze zich bevinden. Het bericht wordt verzonden naar alle clients via hun respectieve servers. Dit proces wordt geïllustreerd in het volgende diagram:

Redis backplane, bericht verzonden van één server naar alle clients

De Redis-backplane is de aanbevolen schaalvergrotingsbenadering voor apps die op uw eigen infrastructuur worden gehost. Als er sprake is van een aanzienlijke verbindingslatentie tussen uw datacenter en een Azure-datacenter, is Azure SignalR Service mogelijk geen praktische optie voor on-premises apps met een lage latentie of hoge doorvoervereisten.

SignalR De azure-servicevoordelen die eerder zijn genoteerd, zijn nadelen voor het Redis-backplane:

  • Plaksessies, ook wel clientaffiniteit genoemd, zijn vereist, behalve wanneer beide van de volgende waar zijn:
    • Alle clients zijn geconfigureerd om alleen WebSockets te gebruiken.
    • De instelling SkipNegotiation is ingeschakeld in de clientconfiguratie. Zodra een verbinding op een server is gestart, moet de verbinding op die server blijven.
  • Een SignalR app moet worden uitgeschaald op basis van het aantal clients, zelfs als er maar weinig berichten worden verzonden.
  • Een SignalR app gebruikt aanzienlijk meer verbindingsresources dan een web-app zonder SignalR.

IIS-beperkingen voor Windows-client-OS

Windows 10 en Windows 8.x zijn clientbesturingssystemen. IIS op clientbesturingssystemen heeft een limiet van 10 gelijktijdige verbindingen. SignalR's verbindingen zijn:

  • Tijdelijk en vaak opnieuw tot stand gebracht.
  • Niet direct verwijderd als het niet langer wordt gebruikt.

De voorgaande voorwaarden maken het waarschijnlijk dat de limiet van 10 verbindingen voor een clientbesturingssysteem wordt bereikt. Wanneer een clientbesturingssysteem wordt gebruikt voor ontwikkeling, raden we het volgende aan:

  • Vermijd IIS.
  • Gebruik Kestrel of IIS Express als implementatiedoelen.

Linux met Nginx

Hieronder vindt u de minimaal vereiste instellingen voor het inschakelen van WebSockets, ServerSentEvents en LongPolling voor SignalR:

http {
  map $http_connection $connection_upgrade {
    "~*Upgrade" $http_connection;
    default keep-alive;
  }

  server {
    listen 80;
    server_name example.com *.example.com;

    # Configure the SignalR Endpoint
    location /hubroute {
      # App server url
      proxy_pass http://localhost:5000;

      # Configuration for WebSockets
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection $connection_upgrade;
      proxy_cache off;
      # WebSockets were implemented after http/1.0
      proxy_http_version 1.1;

      # Configuration for ServerSentEvents
      proxy_buffering off;

      # Configuration for LongPolling or if your KeepAliveInterval is longer than 60 seconds
      proxy_read_timeout 100s;

      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
    }
  }
}

Wanneer er meerdere back-endservers worden gebruikt, moeten plaksessies worden toegevoegd om te voorkomen dat SignalR verbindingen van servers wisselen tijdens de verbinding. Er zijn meerdere manieren om sticky sessions toe te voegen in Nginx. Hieronder ziet u twee benaderingen, afhankelijk van wat u beschikbaar hebt.

Het volgende wordt toegevoegd naast de vorige configuratie. In de volgende voorbeelden backend is dit de naam van de groep servers.

Met Nginx Open Source kunt ip_hash u verbindingen routeren naar een server op basis van het IP-adres van de client:

http {
  upstream backend {
    # App server 1
    server localhost:5000;
    # App server 2
    server localhost:5002;

    ip_hash;
  }
}

Met Nginx Plus kunt sticky u een cookie aan aanvragen toevoegen en de aanvragen van de gebruiker vastmaken aan een server:

http {
  upstream backend {
    # App server 1
    server localhost:5000;
    # App server 2
    server localhost:5002;

    sticky cookie srv_id expires=max domain=.example.com path=/ httponly;
  }
}

Wijzig ten slotte proxy_pass http://localhost:5000 in de server sectie in proxy_pass http://backend.

Zie NGINX als een WebSocket-proxy voor meer informatie over WebSockets via Nginx.

Zie NGINX load balancing voor meer informatie over belastingverdeling en sticky sessions.

Zie het volgende artikel voor meer informatie over ASP.NET Core met Nginx:

Derde partij backplane-leveranciers SignalR

Volgende stappen

Zie de volgende bronnen voor meer informatie: