écaillage ASP.NET SignalR Applications pour des performances optimales

Introduction

ASP.NET est une plate-forme très populaire pour le développement d'applications Web en temps réel, car elle offre aux développeurs un riche ensemble de fonctionnalités d'aide au développement. L'une de ces fonctionnalités est SignalR qui peut vous aider à développer efficacement des applications ASP.NET de traitement de données en temps réel.

SignalR ("R" signifie temps réel) est une bibliothèque open source bien connue pour les développeurs Web ASP.NET qui vous permet de pousser le contenu du côté serveur vers tous les clients connectés dès que les informations sont disponibles. Cela permet de simplifier les efforts de développement nécessaires pour ajouter des fonctionnalités Web en temps réel à vos applications.

Pourquoi devriez-vous utiliser ASP.NET SignalR?

SignalR vous donne la possibilité, au sein de vos applications ASP.NET, d'envoyer instantanément du contenu de code côté serveur vers des clients légers connectés, au fur et à mesure qu'il devient disponible au lieu d'attendre que les clients fassent une autre demande de nouvelles données. Les clients n'ont plus besoin de s'appuyer sur le mécanisme d'interrogation HTTP typique et à la place, SignalR utilise un mécanisme push pour que le nouveau contenu soit mis à la disposition des clients. Cela permet d'améliorer les performances globales de l'application et l'expérience utilisateur.

SignalR a une API très simple qui est très facile à utiliser pour appeler des fonctions JavaScript côté client dans le navigateur client directement depuis le côté serveur. Il utilise des appels de procédure à distance (RPC) pour invoquer la communication client-serveur et fournit également un code .NET complet autour de la gestion de la connexion client-serveur.

SignalR gère la fonctionnalité de communication complète entre les serveurs et les clients et vous n'avez pas besoin de l'implémenter vous-même. Afin d'avoir un échange de messages ultra-rapide, une couche de transport est intégrée à SignalR. Tout ce que vous avez à faire est d'introduire les ressources SignalR dans votre application ASP.NET et de commencer à utiliser ses méthodes.

Voici un diagramme de haut niveau pour référence.

SignalR gère toutes les connexions en interne et au niveau du backend, les Web Sockets sont utilisés s'ils sont pris en charge par le client (HTML5 et versions ultérieures). Si les Web Sockets ne sont pas disponibles, il revient automatiquement à l'ancien mécanisme de transport si nécessaire. Cela simplifie vos efforts de développement et vous n'avez plus besoin d'écrire et de gérer vous-même ce code de communication.

Créer votre premier ASP.NET SignalR Application

Utiliser SignalR dans votre application est beaucoup plus facile que vous ne le pensez. Dans ce cas, prenons un exemple de Chat Hub. Vous pouvez commencer par créer un simple projet Web ASP.NET avec l'ajout de SignalR. Désormais, pour le programme Chat Hub, vous pouvez appeler des classes hub génériques qui contiennent des méthodes intégrées pour la communication avec les connexions SignalR.

Voici comment importer le Hub Microsoft.AspNet.SignalR classe dans votre exemple de programme qui appelle un exemple message de diffusion sur tous les clients connectés.

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);
      }
   }
}

Figure 2 : Implémentation de la classe SignalR ChatHub

L'exemple suivant définit la méthode dans un client JavaScript.

//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>

Figure 3 : Implémentation de JavaScript

ASP.NET SignalR Cas d'usage

Toute application ASP.NET qui utilise une fonctionnalité Web en temps réel est le bon candidat pour incorporer SignalR dans son architecture. En d'autres termes, il s'agit d'un scénario dans lequel l'application pousse beaucoup de nouveau contenu du serveur vers le client et l'utilisateur doit le consommer à mesure que les données changent.

De même, SignalR peut être utilisé pour améliorer les performances des applications qui utilisent le mécanisme d'interrogation longue AJAX pour récupérer de nouvelles données. Ainsi, dès qu'il y a une mise à jour des données dans l'application ASP.NET, les méthodes JavaScript côté client sont automatiquement appelées par SignalR pour demander les données. Cela garantit que les mises à jour en temps réel sont envoyées instantanément aux clients Web.

Quelques cas d'utilisation populaires pour SignalR sont mentionnés ci-dessous.

1. Systèmes de chat
2. Internet des Objets (IoT)
3. Applications de jeu
4. Systèmes de réservation des compagnies aériennes
5. Candidatures boursières
6. Plus…

Le problème : SignalR n'est pas évolutif prêt à l'emploi

Bien que l'implémentation de la bibliothèque SignalR dans votre application ASP.NET puisse être un choix judicieux, son incapacité à évoluer de manière linéaire peut en fait aller à l'encontre de son objectif. Voici pourquoi:

Comme SignalR travaille sur un modèle basé sur des sockets Web, son déploiement sur un seul serveur fonctionne correctement, tous les messages étant envoyés à tous les clients connectés au serveur Web.

Cependant, un seul serveur peut bientôt atteindre sa capacité en raison de l'augmentation de la charge des demandes d'application. À ce stade, vous devez évoluer en ajoutant d'autres serveurs Web et en créant une "ferme Web". Ce faisant, vos demandes client sont distribuées et peuvent donc également être acheminées vers différents serveurs Web. Un client connecté à un serveur Web via des sockets Web ne recevra pas les messages envoyés par un autre serveur Web. Cela conduira à une situation où les clients ne recevront pas les messages SignalR et resteront désynchronisés.

Ces clients vont en fait attendre que cette fonctionnalité soit poussée par leurs propres serveurs Web respectifs, ce qui augmentera la latence. De plus, dans une application basée sur plusieurs serveurs, il n'est pas nécessaire que tous les serveurs Web appellent les nouvelles données entrantes. Il y a donc de fortes chances que ces nouvelles données ne soient pas du tout transmises aux clients respectifs et que les messages soient complètement manqués.

Prenons l'exemple d'une application Real Time Stock Market, où des milliers de valeurs boursières changent chaque seconde. Dans un tel scénario, les clients finaux ont besoin d'informations précises et absolument correctes chaque fois qu'un prix a changé.

Les marchés boursiers traitent d'énormes quantités de données de transactions élevées et il est très important que toutes les informations soient transmises à tous les utilisateurs en temps opportun. Avoir une batterie de serveurs Web peut entraîner une latence accrue pour certains utilisateurs et certains utilisateurs peuvent complètement manquer des mises à jour importantes. Cela crée une mauvaise expérience utilisateur et aura un impact négatif sur votre entreprise.

Pour contrer ces problèmes, Microsoft offre la possibilité d'utiliser un fond de panier, qui peut être généralement défini comme un magasin de messages central, auquel tous les serveurs Web sont connectés simultanément.

SignalR backplane permet aux serveurs Web de se connecter et de s'envoyer d'abord tous les messages au lieu de les envoyer à leurs propres clients connectés. Backplane diffuse ensuite ces messages à tous les serveurs web qui internes, transmettent ces messages à leurs clients connectés. Cela garantit que tous les messages sont envoyés à tous les clients finaux, même invoqués par le serveur Web auquel le client n'était pas connecté.

SignalR backplane peut être un disque, une base de données, un bus de messages ou un cache distribué en mémoire. Permettez-moi de discuter des options de fond de panier les plus couramment utilisées et de leurs problèmes associés.

Problèmes avec la base de données relationnelle en tant que SignalR Backplane

SignalR est utilisé dans les applications en temps réel traitant d'énormes volumes de données. Le fond de panier doit être capable de gérer une charge de messages extrême et cela aussi de manière rapide et fiable. La base de données relationnelle est couramment utilisée comme fond de panier, ce qui n'est pas très approprié car le fond de panier doit être de nature évolutive.

Prenons un exemple où vous avez une application ASP.NET E-Commerce qui est déployée sur 10 serveurs Web dans une ferme Web. Tous ces 10 serveurs Web ont leurs clients distincts basés sur un navigateur qui leur sont connectés via SignalR et les serveurs Web sont également connectés à un fond de panier qui est une base de données dans ce cas.

Si l'un des serveurs Web génère 1 message chacun faisant un total de 10 messages, ces 10 messages seront transmis au fond de panier et la base de données diffusera alors tous ces messages à tous les 10 serveurs Web connectés. Cela totalise jusqu'à 100 messages diffusés par la base de données.

Imaginez maintenant la même configuration mais l'application est notoirement bavarde et vos serveurs produisent un total de 10000 1000 messages (100000 10000 messages par serveur Web) à tout moment. Le fond de panier devra diffuser 10 messages (XNUMX x XNUMX) en même temps. Vous pouvez voir à quel point il est facile pour la base de données de s'étouffer lorsque le nombre de requêtes augmente.

Voici quelques problèmes lorsque des bases de données relationnelles sont utilisées pour SignalR backplane:

1. Habituellement, la charge de transaction est très élevée et une livraison plus rapide est nécessaire pour exclure le facteur de latence. Les bases de données relationnelles sont lentes et peuvent même s'étouffer sous les pics de charge de traitement des données en temps réel.
2. Étant basée sur un disque, une base de données relationnelle ne peut jamais fonctionner assez rapidement pour atteindre le débit souhaité sous une charge élevée.
3. Plus important encore, les bases de données relationnelles manquent clairement de la capacité de mise à l'échelle linéaire où vous ne pouvez pas ajouter plus de serveurs pour gérer plus de charge.

Problèmes avec Redis as SignalR Backplane

La deuxième option peut être d'utiliser Redis comme votre SignalR backplane qui résout bien que les problèmes liés aux performances et à l'évolutivité que vous rencontrez avec les bases de données relationnelles, mais ce n'est pas non plus un choix approprié à faire. Voici quelques-unes des raisons à cela :

• Redis est un cache distribué basé sur Linux et n'est pas une option .NET native. Utilisation d'un système basé sur Linux pour ASP.NET SignalR n'a pas beaucoup de sens où vous devrez avoir une pile Linux avec Windows et aurez besoin d'une expertise distincte pour gérer et surveiller cette configuration.
• Un développeur .NET aspire toujours à une pile .Net 100 % native lorsqu'il développe de telles applications Web en temps réel. Il sera contre-intuitif de gérer une solution .NET non native comme un SignalR backplane tandis que tous les autres modules d'application sont 100 % natifs .NET.
• Une autre limite dans Redis est que sa version .NET Windows portée sur la plate-forme Microsoft Azure est pleine de bogues selon les avis des utilisateurs qui s'abstient même Redis d'utiliser leur propre version .NET Windows portée dans Azure.

Cela rend Redis, un choix ambivalent entre les développeurs .NET du point de vue de la compatibilité.

La solution : utiliser NCache as SignalR Backplane

NCache est un système de mise en cache distribué en mémoire développé par Alachisoft et est l'option la plus appropriée pour être utilisée comme fond de panier. NCache est un cluster de serveurs de cache peu coûteux qui sont regroupés pour fournir une capacité de mémoire et de processeur évolutive. Il s'agit essentiellement d'une capacité logique de plusieurs serveurs dotée de toutes les fonctionnalités à utiliser en tant que SignalR backplane.

La meilleure partie de l'utilisation NCache comme votre SignalR backplane est qu'il s'agit de .NET natif à cent pour cent et que vous n'avez pas besoin de modifications majeures du code dans votre application ASP.NET. C'est comme une option plug-nplay qui vous donne non seulement la possibilité de gérer les messages de votre fond de panier, mais vous pouvez également surveiller ces messages à l'aide du NCache outils de suivi des performances.

NCache fournit l'extension SignalR à utiliser comme fond de panier dans vos applications ASP.NET.

Tous vos serveurs Web de la ferme Web sont enregistrés auprès de NCache en utilisant NCache Plate-forme de messagerie Pub/Sub. Vos serveurs Web enregistrent un sujet spécifique pour les messages SignalR et NCache diffuse ensuite ces messages à tous les serveurs Web. Il s'agit essentiellement d'une structure de transmission de messages bidirectionnelle où vos éditeurs peuvent être abonnés et inversement.

Brancher NCache en tant que fond de panier dans votre application basée sur SignalR, il vous suffit d'introduire une ligne de code, qui est mentionnée dans le guide d'implémentation étape par étape.

Constat NCache Le fond de panier est-il meilleur que SQL Server ?

Pour obtenir la meilleure expérience utilisateur dans votre application ASP.NET, NCache agit comme un fond de panier très rapide, fiable et évolutif pour gérer d'énormes quantités de notifications. Ci-dessous sont mentionnés quelques avantages clés de l'utilisation NCache au lieu de RDBM comme fond de panier.

1. NCache est linéairement évolutif (débit élevé et faible latence)

   La caractéristique la plus importante de NCache fond de panier est qu'il offre un débit maximal et une latence minimale. Il gère de manière transparente et rapide de grandes quantités de données en gardant tout le traitement des messages en mémoire, éliminant ainsi tout risque d'augmentation de la latence.

   Pour livrer tous les messages à temps, NCache offre un débit maximal pendant la transmission en répartissant la charge sur tous les serveurs disponibles dans le cluster de cache et vous permet également d'ajouter plus de serveurs au moment de l'exécution.

   Voici quelques chiffres de référence de performance pour une référence.

   

   Cela vous donne une évolutivité linéaire globale au sein de votre architecture d'application et vous n'avez pas à vous soucier de la baisse des performances de votre application, en particulier sous des charges extrêmes.

2. NCache est extrêmement fiable

   La deuxième caractéristique de NCache fond de panier est son extrême fiabilité. Pour assurer une livraison garantie des messages, en particulier dans le cas d'applications critiques, NCache peut être utilisé comme fond de panier afin que vous n'ayez pas à vous soucier de la perte de vos messages en raison d'une panne de serveur ou d'une panne pour maintenance. Il conserve la sauvegarde de chaque serveur de cache utilisé dans le cluster pour SignalR backplane qui est automatiquement disponible en cas de panne d'un serveur.

   L'extrême fiabilité de NCache est attribué à sa caractéristique qui diffuse tous les messages vers chaque serveur Web connecté au fond de panier. La sauvegarde de vos données sur d'autres serveurs garantit que pendant que vos applications critiques transfèrent de lourdes charges utiles, il n'y a aucun risque de perte de données.

3. NCache est hautement disponible

   Une autre caractéristique importante de NCache fond de panier est sa haute disponibilité. Avec NCache installé comme votre SignalR backplane, votre système devient hautement disponible car vos messages sont désormais transférés via un cluster de cache toujours actif.

   NCache L'architecture garantit la fonctionnalité de haute disponibilité grâce à son « cluster de cache toujours actif » qui peut être basé sur l'une de nos différentes topologies de mise en cache. Par exemple, la topologie "Partition-réplica" vous fournit une partition active sur tous les serveurs et chaque serveur en possède une sauvegarde. Ainsi, si un serveur tombe en panne, les clients le détectent automatiquement et basculent leur connexion vers les autres nœuds survivants.

   Le cluster de cache de NCache est capable de fonctionner même si un seul serveur est opérationnel et c'est ce dont vous avez besoin au minimum pour un scénario de disponibilité à cent pour cent. Cette fonctionnalité est payante dans les cas où vos serveurs sont soit frappés par une calamité naturelle, soit vous les arrêtez intentionnellement à des fins de maintenance. En bref, les topologies pragmatiques de mise en cache de NCache vous aider à atteindre une disponibilité de 100 % dans vos applications basées sur SignalR.

   

Constat NCache est mieux que Redis?

NCache est aussi mieux que Redis du point de vue des fonctionnalités. Pour éliminer toutes les lacunes rencontrées par les développeurs dans Redis système de cache distribué, NCache a ces trois caractéristiques superlatives.

• .NET natif : NCache est 100% natif .NET et convient donc parfaitement aux applications ASP.NET utilisant SignalR. D'autre part, Redis provient d'un arrière-plan Linux et n'est pas un cache .NET natif.
• Plus rapide que Redis: NCache est en fait plus vite que Redis. NCache La fonctionnalité de cache client donne NCache une amélioration significative des performances.
• Plus de fonctionnalités: NCache offre un certain nombre de fonctionnalités de cache distribué très importantes qui Redis ne fait pas. Voir plus de détails dans ce Redis vs NCache

Exécution NCache SignalR Backplane

Vous pouvez déployer NCache comme votre SignalR Backplane avec juste un changement d'une ligne et vous pouvez suivre le tutoriel étape par étape ci-dessous pour équiper vos applications pour cela.

1. Installer le package NuGet

   Commencez par installer le Alachisoft.NCache.SignalR package NuGet à votre application en exécutant la commande suivante dans la console du gestionnaire de packages :

   Install-Package Alachisoft.NCache.SignalR

2. Inclure l'espace de noms

   Dans votre Démarrage.cs fichier, incluez ces deux espaces de noms comme indiqué ci-dessous :

   • Alachisoft.NCache.SignalR
   • Microsoft.AspNet.SignalRMicrosoft.AspNet.SignalR
3. Modifier Web.config

   Dans votre fichier Web.config, vous devrez définir le cacheName et clé d'événement dans l' tag:

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

   Figure 8 : Modifications de Web.config

4. Inscription NCache as SignalR Backplane pour votre candidature

   Enregistrez une instance de l'utilisationNCache() dans Startup.cs de votre application dans l'une des surcharges suivantes :

   Surcharge 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();
   	}
   }
   

   Figure 9 : Enregistrement NCache SignalR Backplane (Surcharge 1)

   Surcharge 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();
   	}
    ...

   Figure 10 : Enregistrement NCache SignalR Backplane (Surcharge 2)

Conclusion

Pour conclure le tout, NCache est essentiellement un cache distribué en mémoire basé sur .NET qui peut être utilisé dans toutes les applications Web ASP.NET en temps réel comme fond de panier pour votre SignalR afin d'augmenter les performances de votre application Web.

Les caractéristiques qui le distinguent des autres options disponibles incluent ses performances ultra-rapides, sa disponibilité à 100 %, la fiabilité des données, la livraison garantie des messages et la capacité de maintenir le débit maximal avec une latence minimale.

Que faire ensuite?

• NCache Détails
• Comparaison Des Éditions
• Télécharger NCache
• NCache vs AppFabric
• NCache vs Redis
• NCache vs Memcached