Skalierung ASP.NET SignalR Anwendungen für Spitzenleistung

Einleitung

ASP.NET ist eine sehr beliebte Plattform für die Entwicklung von Echtzeit-Webanwendungen, da sie Entwicklern umfangreiche Entwicklungsunterstützungsfunktionen bietet. Eine dieser Funktionen ist SignalR, das Ihnen bei der effizienten Entwicklung von ASP.NET-Anwendungen zur Echtzeit-Datenverarbeitung helfen kann.

SignalR („R“ steht für Real-Time) ist eine bekannte Open-Source-Bibliothek für ASP.NET-Webentwickler, mit der Sie Inhalte von der Serverseite an alle verbundenen Clients übertragen können, sobald Informationen verfügbar sind. Dies trägt dazu bei, den Entwicklungsaufwand zu vereinfachen, der zum Hinzufügen von Echtzeit-Webfunktionen zu Ihren Anwendungen erforderlich ist.

Warum sollten Sie verwenden? ASP.NET SignalR?

SignalR bietet Ihnen in Ihren ASP.NET-Anwendungen die Möglichkeit, serverseitigen Code Inhalte sofort an verbundene Thin Clients weiterzuleiten, sobald diese verfügbar sind, anstatt darauf zu warten, dass Clients eine weitere Anfrage nach neuen Daten stellen. Clients müssen sich nicht mehr auf den typischen HTTP-Abfragemechanismus verlassen. Stattdessen verwendet SignalR den Push-Mechanismus, um den Clients neue Inhalte zur Verfügung zu stellen. Dies trägt dazu bei, die Gesamtleistung der Anwendung und das Benutzererlebnis zu verbessern.

SignalR verfügt über eine sehr einfache API, mit der sich sehr einfach clientseitige JavaScript-Funktionen im Client-Browser direkt vom Server aus aufrufen lassen. Es verwendet Remoteprozeduraufrufe (RPC), um die Client-Server-Kommunikation aufzurufen, und stellt außerdem vollständigen .NET-Code für die Client-Server-Verbindungsverwaltung bereit.

SignalR übernimmt die komplette Kommunikationsfunktionalität zwischen Servern und Clients und Sie müssen diese nicht selbst implementieren. Um einen superschnellen Nachrichtenaustausch zu ermöglichen, ist in SignalR eine Transportschicht integriert. Sie müssen lediglich SignalR-Ressourcen in Ihre ASP.NET-Anwendung einführen und mit der Nutzung ihrer Methoden beginnen.

Hier ist ein allgemeines Diagramm als Referenz.

SignalR verwaltet alle Verbindungen intern und im Backend. Web Sockets werden verwendet, sofern dies vom Client unterstützt wird (HTML5 und höher). Wenn Web Sockets nicht verfügbar sind, wird bei Bedarf automatisch auf einen älteren Transportmechanismus zurückgegriffen. Dies vereinfacht Ihre Entwicklungsbemühungen und Sie müssen diesen Kommunikationscode nicht mehr selbst schreiben und verwalten.

Erstellen Sie Ihr erstes ASP.NET SignalR Anwendung

Die Verwendung von SignalR in Ihrer Anwendung ist viel einfacher als Sie denken. Nehmen wir in diesem Fall ein Beispiel für einen Chat-Hub. Sie können damit beginnen, ein einfaches ASP.NET-Webprojekt mit dem Zusatz SignalR zu erstellen. Jetzt können Sie für das Chat Hub-Programm generische Hub-Klassen aufrufen, die integrierte Methoden für die Kommunikation mit SignalR-Verbindungen enthalten.

So importieren Sie die Microsoft.AspNet.SignalR-Hub Klasse in Ihrem Beispielprogramm, die ein Beispiel aufruft BroadcastMessage auf allen angeschlossenen Clients.

namespace SignalRChat
{
   public class ChatHub : Hub
   {
      public void Send(string name, string message)
      {
         // Call the broadcastMessage method to update clients.
         Clients.All.broadcastMessage(name, message);
      }
   }
}

Abbildung 2: Implementierung der SignalR ChatHub-Klasse

Das folgende Beispiel definiert die Methode in einem JavaScript-Client-Ende.

//Add script to update the page and send messages.
   <script type="text/javascript">
      $(function () {
         //Declare a proxy to reference the hub.
         var chat = $.connection.chatHub;
		 
         // Create a function that the hub can call to broadcast messages.
         } chat.client.broadcastMessage = function (name, message) {
         // Html encode display name and message.
         ...
         });
   </script>

Abbildung 3: JavaScript-Implementierung

ASP.NET SignalR Anwendungsbeispiele

Jede ASP.NET-Anwendung, die eine Echtzeit-Webfunktionalität nutzt, ist der richtige Kandidat für die Integration von SignalR in ihre Architektur. Mit anderen Worten handelt es sich um ein Szenario, in dem die Anwendung viele neue Inhalte vom Server an den Client überträgt und der Benutzer diese konsumieren muss, wenn sich Daten ändern.

In ähnlicher Weise kann SignalR verwendet werden, um die Leistung von Anwendungen zu verbessern, die den AJAX-Long-Polling-Mechanismus zum Abrufen neuer Daten verwenden. Sobald es also zu einer Datenaktualisierung in der ASP.NET-Anwendung kommt, werden von SignalR automatisch clientseitige JavaScript-Methoden aufgerufen, um die Daten anzufordern. Dadurch wird sichergestellt, dass Echtzeitaktualisierungen sofort an die Webclients gesendet werden.

Nachfolgend werden einige beliebte Anwendungsfälle für SignalR aufgeführt.

1. Chat-Systeme
2. Internet der Dinge (IoT)
3. Gaming-Anwendungen
4. Flugbuchungssysteme
5. Börsenanträge
6. Mehr…

Das Problem: SignalR ist nicht sofort skalierbar

Obwohl die Implementierung der SignalR-Bibliothek in Ihrer ASP.NET-Anwendung eine kluge Wahl sein kann, kann ihre Unfähigkeit zur linearen Skalierung tatsächlich ihren gesamten Zweck zunichte machen. Hier ist der Grund:

Da SignalR an einem Web-Sockets-basierten Modell arbeitet, funktioniert die Bereitstellung auf einem einzigen Server einwandfrei, wobei alle Nachrichten an alle mit dem Webserver verbundenen Clients gesendet werden.

Aufgrund der erhöhten Anwendungsanforderungslast kann jedoch die Kapazität eines einzelnen Servers bald erschöpft sein. An diesem Punkt müssen Sie die Skalierung durchführen, indem Sie weitere Webserver hinzufügen und eine „Webfarm“ erstellen. Dabei werden Ihre Client-Anfragen verteilt und können somit auch an verschiedene Webserver weitergeleitet werden. Ein Client, der über Web-Sockets mit einem Webserver verbunden ist, empfängt keine Nachrichten, die von einem anderen Webserver gesendet werden. Dies führt dazu, dass Clients keine SignalR-Nachrichten empfangen und nicht synchron bleiben.

Diese Clients werden tatsächlich warten, bis diese Funktionalität von ihren jeweiligen Webservern bereitgestellt wird, was die Latenz erhöht. Außerdem ist es in einer auf mehreren Servern basierenden Anwendung nicht notwendig, dass alle Webserver die eingehenden neuen Daten aufrufen. Es besteht also eine hohe Wahrscheinlichkeit, dass diese neuen Daten überhaupt nicht an die jeweiligen Clients weitergeleitet werden und Nachrichten vollständig übersehen werden.

Nehmen wir als Beispiel eine Echtzeit-Börsenanwendung, bei der sich jede Sekunde Tausende von Aktienwerten ändern. In einem solchen Szenario benötigen die Endkunden bei jeder Preisänderung genaue und absolut korrekte Informationen.

An den Aktienmärkten werden große Mengen an Transaktionsdaten verarbeitet, und es ist sehr wichtig, dass alle Informationen zeitnah an alle Benutzer weitergegeben werden. Das Vorhandensein einer Webfarm kann für einige Benutzer zu einer erhöhten Latenz führen, und einige Benutzer verpassen möglicherweise wichtige Updates vollständig. Dies führt zu einer schlechten Benutzererfahrung und wirkt sich negativ auf Ihr Unternehmen aus.

Um diesen Problemen entgegenzuwirken, bietet Microsoft die Möglichkeit, eine Backplane zu verwenden, die allgemein als zentraler Nachrichtenspeicher definiert werden kann, an den alle Webserver gleichzeitig angeschlossen sind.

SignalR backplane Ermöglicht es Webservern, eine Verbindung herzustellen und alle Nachrichten zuerst an sich selbst zu senden, anstatt sie an ihre eigenen verbundenen Clients zu senden. Backplane sendet diese Nachrichten dann an alle Webserver, die diese Nachrichten dann an ihre angeschlossenen Clients weiterleiten. Dadurch wird sichergestellt, dass alle Nachrichten an alle End-Clients gesendet werden, auch wenn sie von einem Webserver aufgerufen werden, mit dem der Client nicht verbunden war.

SignalR backplane Dies kann eine Festplatte, eine Datenbank, ein Nachrichtenbus oder ein verteilter In-Memory-Cache sein. Lassen Sie mich die am häufigsten verwendeten Backplane-Optionen und die damit verbundenen Probleme besprechen.

Probleme mit relationalen Datenbanken als SignalR Backplane

SignalR wird in Echtzeitanwendungen verwendet, die große Datenmengen verarbeiten. Die Backplane muss in der Lage sein, die extreme Nachrichtenlast schnell und zuverlässig zu bewältigen. Relationale Datenbanken werden häufig als Rückwandplatine verwendet, was nicht sehr geeignet ist, da die Rückwandplatine von Natur aus skalierbar sein muss.

Nehmen wir ein Beispiel, bei dem Sie über eine ASP.NET E-Commerce-Anwendung verfügen, die auf 10 Webservern in einer Webfarm bereitgestellt wird. Alle diese 10 Webserver verfügen über separate browserbasierte Clients, die über SignalR mit ihnen verbunden sind, und die Webserver sind auch mit einer Backplane verbunden, die in diesem Fall eine Datenbank ist.

Wenn einer der Webserver jeweils 1 Nachricht generiert, also insgesamt 10 Nachrichten, werden diese 10 Nachrichten an die Rückwandplatine übertragen und die Datenbank sendet dann alle diese Nachrichten an alle angeschlossenen 10 Webserver. Dies sind insgesamt bis zu 100 Nachrichten, die von der Datenbank gesendet werden.

Stellen Sie sich nun das gleiche Setup vor, aber die Anwendung ist bekanntermaßen gesprächig und Ihre Server produzieren zu jedem Zeitpunkt insgesamt 10000 Nachrichten (1000 Nachrichten pro Webserver). Die Backplane muss 100000 Nachrichten (10000 x 10) gleichzeitig senden. Sie sehen, wie schnell die Datenbank überlastet wird, wenn die Anzahl der Anfragen steigt.

Hier sind einige Probleme, wenn relationale Datenbanken verwendet werden SignalR backplane:

1. Normalerweise ist die Transaktionslast sehr hoch und eine schnellere Lieferung ist erforderlich, um den Latenzfaktor auszuschließen. Relationale Datenbanken sind langsam und können bei Spitzenlasten bei der Echtzeit-Datenverarbeitung sogar zum Erliegen kommen.
2. Da eine relationale Datenbank auf einer Festplatte basiert, kann sie nie schnell genug arbeiten, um unter hoher Last den gewünschten Durchsatz zu erreichen.
3. Am wichtigsten ist, dass den relationalen Datenbanken eindeutig die Fähigkeit zur linearen Skalierung fehlt, sodass Sie nicht mehr Server hinzufügen können, um eine höhere Last zu bewältigen.

Probleme mit Redis as SignalR Backplane

Die zweite Option kann die Verwendung sein Redis wie dein SignalR backplane Dies löst zwar Leistungs- und Skalierbarkeitsprobleme, die bei relationalen Datenbanken auftreten, ist aber auch keine geeignete Wahl. Hier sind einige der Gründe hierfür:

• Redis ist ein Linux-basierter verteilter Cache und keine native .NET-Option. Verwendung eines Linux-basierten Systems für ASP.NET SignalR macht wenig Sinn, wenn Sie einen Linux-Stack zusammen mit Windows benötigen und separates Fachwissen benötigen, um dieses Setup zu verwalten und zu überwachen.
• Ein .NET-Entwickler sehnt sich bei der Entwicklung solcher Echtzeit-Webanwendungen immer nach einem 100 % nativen .NET-Stack. Es wäre kontraintuitiv, eine nicht-native .NET-Lösung als zu verwalten SignalR backplane während alle anderen Anwendungsmodule zu 100 % natives .NET sind.
• Eine weitere Einschränkung in Redis ist, dass seine auf .NET Windows portierte Version auf der Microsoft Azure-Plattform laut Benutzerbewertungen voller Fehler ist, was sogar unterlassen wird Redis von der Verwendung ihrer eigenen portierten .NET Windows-Version in Azure abhalten.

Dadurch Redis, eine ambivalente Entscheidung zwischen .NET-Entwicklern aus Kompatibilitätssicht.

Die Lösung: Nutzen NCache as SignalR Backplane

NCache ist ein In-Memory Distributed Caching System, das von entwickelt wurde Alachisoft und ist die am besten geeignete Option für den Einsatz als Rückwandplatine. NCache ist ein Cluster kostengünstiger Cache-Server, die zur Bereitstellung skalierbarer Speicher- und CPU-Kapazität zusammengefasst werden. Es handelt sich im Wesentlichen um eine logische Kapazität mehrerer Server, die über alle Funktionen verfügt, die als Server verwendet werden können SignalR backplane.

Das Beste an der Verwendung NCache wie dein SignalR backplane ist, dass es hundertprozentig natives .NET ist und Sie keine größeren Codeänderungen in Ihrer ASP.NET-Anwendung benötigen. Es ist wie eine Plug-and-Play-Option, die Ihnen nicht nur die Möglichkeit gibt, Ihre Backplane-Nachrichten zu verwalten, sondern Sie können diese Nachrichten auch mit dem überwachen NCache Tools zur Leistungsüberwachung.

NCache Bietet eine SignalR-Erweiterung zur Verwendung als Backplane in Ihren ASP.NET-Anwendungen.

Alle Ihre Webserver in der Webfarm sind bei registriert NCache Verwendung von NCache Pub/Sub-Messaging-Plattform. Ihre Webserver registrieren ein bestimmtes Thema für SignalR-Nachrichten und NCache sendet diese Nachrichten dann an alle Webserver. Es handelt sich im Grunde um eine bidirektionale Nachrichtenübertragungsstruktur, bei der Ihre Herausgeber Abonnenten sein können und umgekehrt.

Einstecken NCache Als Backplane in Ihrer SignalR-basierten Anwendung müssen Sie nur eine Codezeile einführen, die in der Schritt-für-Schritt-Implementierungsanleitung erwähnt wird.

Warum NCache Backplane ist besser als SQL Server?

Um die beste Benutzererfahrung in Ihrer ASP.NET-Anwendung zu erzielen, NCache fungiert als sehr schnelle, zuverlässige und skalierbare Backplane zur Verarbeitung großer Mengen an Benachrichtigungen. Nachfolgend sind einige wichtige Vorteile der Verwendung aufgeführt NCache anstelle von RDBMs als Backplane.

1. NCache ist linear skalierbar (hoher Durchsatz und niedrige Latenz)

   Das wichtigste Merkmal von NCache Die Besonderheit der Backplane besteht darin, dass sie maximalen Durchsatz und minimale Latenz bietet. Es verarbeitet große Datenmengen nahtlos und schnell, indem es die gesamte Nachrichtenverarbeitung im Speicher behält und so die Möglichkeit einer Erhöhung der Latenz ausschließt.

   Um alle Nachrichten rechtzeitig zu übermitteln, NCache Bietet maximalen Durchsatz während der Übertragung, indem die Last auf alle verfügbaren Server im Cache-Cluster verteilt wird, und ermöglicht Ihnen außerdem, zur Laufzeit weitere Server hinzuzufügen.

   Als Referenz finden Sie hier einige Leistungs-Benchmark-Zahlen.

   

   Dadurch erhalten Sie eine insgesamt lineare Skalierbarkeit innerhalb Ihrer Anwendungsarchitektur und müssen sich keine Sorgen machen, dass die Leistung Ihrer Anwendung, insbesondere unter extremer Belastung, abnimmt.

2. NCache ist äußerst zuverlässig

   Das zweite Merkmal von NCache Backplane ist ihre extreme Zuverlässigkeit. Um eine garantierte Nachrichtenzustellung insbesondere bei geschäftskritischen Anwendungen sicherzustellen, NCache kann als Rückwandplatine verwendet werden, sodass Sie sich keine Sorgen machen müssen, dass Ihre Nachrichten verloren gehen, wenn Server ausfallen oder wegen Wartungsarbeiten heruntergefahren werden. Es führt eine Sicherung jedes im Cluster verwendeten Cache-Servers durch SignalR backplane die automatisch verfügbar gemacht wird, falls ein Server ausfällt.

   Die extreme Zuverlässigkeit von NCache wird auf seine Eigenschaft zurückgeführt, dass alle Nachrichten an jeden einzelnen Webserver gesendet werden, der mit der Rückwandplatine verbunden ist. Durch die Sicherung Ihrer Daten auf anderen Servern wird sichergestellt, dass bei der Übertragung großer Nutzlasten durch Ihre geschäftskritischen Anwendungen keine Gefahr eines Datenverlusts besteht.

3. NCache ist hochverfügbar

   Ein weiteres wichtiges Merkmal von NCache Backplane ist ihre hohe Verfügbarkeit. Mit NCache als Ihr installiert SignalR backplane, wird Ihr System hochverfügbar, da Ihre Nachrichten jetzt über einen immer aktiven Cache-Cluster übertragen werden.

   NCache Die Architektur gewährleistet die Hochverfügbarkeitsfunktion durch ihren „Always Active Cache Cluster“, der auf einer unserer verschiedenen Caching-Topologien basieren kann. Die „Partition-Replica“-Topologie bietet Ihnen beispielsweise eine aktive Partition auf allen Servern und jeder Server verfügt über ein Backup davon. Wenn also ein Server ausfällt, erkennen die Clients dies automatisch und stellen ihre Verbindung auf die anderen überlebenden Knoten um.

   Der Cache-Cluster von NCache ist in der Lage, auch dann zu funktionieren, wenn nur ein Server aktiv ist und das ist es, was Sie mindestens für ein hundertprozentiges Betriebszeitszenario benötigen. Diese Funktion zahlt sich aus, wenn Ihre Server entweder von einer Naturkatastrophe heimgesucht werden oder Sie sie zu Wartungszwecken absichtlich herunterfahren. Kurz gesagt, die pragmatischen Caching-Topologien von NCache Helfen Sie dabei, eine 100-prozentige Verfügbarkeit Ihrer SignalR-basierten Anwendungen zu erreichen.

   

Warum NCache ist besser als Redis?

NCache ist auch besser als Redis aus Sicht der Funktionen. Um alle Mängel auszuschließen, mit denen Entwickler konfrontiert sind Redis verteiltes Cache-System, NCache verfügt über diese drei Superlative.

• Natives .NET: NCache ist zu 100 % natives .NET und eignet sich daher perfekt für ASP.NET-Anwendungen mit SignalR. Andererseits, Redis stammt aus einem Linux-Hintergrund und ist kein nativer .NET-Cache.
• Schneller als Redis: NCache ist tatsächlich schneller als Redis. NCache Client-Cache-Funktion gibt NCache eine deutliche Leistungssteigerung.
• Mehr Funktionen: NCache bietet eine Reihe sehr wichtiger verteilter Cache-Funktionen, die Redis nicht. Weitere Einzelheiten finden Sie in diesem Redis vs NCache

Umsetzung NCache SignalR Backplane

Sie können bereitstellen NCache wie dein SignalR Backplane Mit nur einer Änderung in einer Zeile können Sie der folgenden Schritt-für-Schritt-Anleitung folgen, um Ihre Anwendungen dafür auszurüsten.

1. Installieren Sie das NuGet-Paket

   Beginnen Sie mit der Installation von Alachisoft.NCache.SignalR Fügen Sie das NuGet-Paket Ihrer Anwendung hinzu, indem Sie den folgenden Befehl in der Paket-Manager-Konsole ausführen:

   Install-Package Alachisoft.NCache.SignalR

2. Namespace einschließen

   In Ihrem Startup.cs Fügen Sie in der Datei diese beiden Namespaces wie unten beschrieben ein:

   • Alachisoft.NCache.SignalR
   • Microsoft.AspNet.SignalR
3. Ändern Sie Web.config

   In Ihrer Web.config-Datei müssen Sie den CacheName und definieren eventKey der tag:

   <configuration>
      <appSettings>
         <add key="cache" value="myPartitionedCache"/>
         <add key="eventKey" value="Chat"/>
      </appSettings>
   </configuration>

   Abbildung 8: Web.config-Änderungen

4. Registrieren NCache as SignalR Backplane für Ihre Bewerbung

   Registrieren Sie eine Instanz der VerwendungNCache()-Methode in Startup.cs Ihrer Anwendung in einer der folgenden Überladungen:

   Überlastung 1:

   public static IDependencyResolver
   	UseNCache(this IDependencyResolver resolver, string cacheName, string eventKey);
   public class Startup
   {
    	public void Configuration(IAppBuilder app)
   	{
   		string cache, eventKey;
   		cache = ConfigurationManager.AppSettings["cache"];
   		eventKey = ConfigurationManager.AppSettings["eventKey"];
   		//using NCache SignalR
   		GlobalHost.DependencyResolver.UseNCache(cache, eventKey);
   		app.MapSignalR();
   	}
   }
   

   Abbildung 9: Registrieren NCache SignalR Backplane (Überlastung 1)

   Überlastung 2:

   public static IDependencyResolver
   UseNCache(this IDependencyResolver resolver, NCacheScaleoutConfiguration configuration);
   
   public class Startup
   {
   	public void Configuration(IAppBuilder app)
   	{
   		string cache, eventKey;
   		cache = ConfigurationManager.AppSettings["cache"];
   		eventKey = ConfigurationManager.AppSettings["eventKey"];
   		NCacheScaleoutConfiguration configuration = new NCacheScaleoutConfiguration(cache, eventKey);
   		//using NCache SignalR
   		GlobalHost.DependencyResolver.UseNCache(configuration);
   		app.MapSignalR();
   	}
    ...

   Abbildung 10: Registrieren NCache SignalR Backplane (Überlastung 2)

Zusammenfassung

Um das Ganze abzuschließen, NCache ist im Wesentlichen ein .NET-basierter verteilter In-Memory-Cache, der in allen Echtzeit-ASP.NET-Webanwendungen als Backplane für Ihr SignalR verwendet werden kann, um die Leistung Ihrer Webanwendung zu steigern.

Zu den Merkmalen, die es von anderen verfügbaren Optionen unterscheiden, gehören seine superschnelle Leistung, 100 % Verfügbarkeit, Datenzuverlässigkeit, garantierte Zustellung von Nachrichten und die Fähigkeit, den maximalen Durchsatz bei minimaler Latenz aufrechtzuerhalten.

Was macht man als nächstes?

• NCache Details
• Editionsvergleich
• Herunterladen NCache
• NCache vs AppFabric
• NCache vs Redis
• NCache vs Memcached