scalata ASP.NET SignalR Applicazioni per le massime prestazioni

Introduzione

ASP.NET è una piattaforma molto popolare per lo sviluppo di applicazioni Web in tempo reale poiché fornisce agli sviluppatori un ricco set di funzionalità di assistenza allo sviluppo. Una di queste funzionalità è SignalR, che può aiutarti a sviluppare in modo efficiente applicazioni ASP.NET di elaborazione dati in tempo reale.

SignalR ("R" sta per real-time) è una nota libreria open source per sviluppatori Web ASP.NET che consente di inviare il contenuto dal lato server a tutti i client connessi non appena le informazioni diventano disponibili. Ciò consente di semplificare gli sforzi di sviluppo necessari per aggiungere funzionalità Web in tempo reale alle applicazioni.

Perché dovresti usare ASP.NET SignalR?

SignalR ti offre la possibilità all'interno delle tue applicazioni ASP.NET di avere il contenuto push del codice lato server ai thin client connessi istantaneamente, poiché diventa disponibile invece di attendere che i client effettuino un'altra richiesta di nuovi dati. I client non devono più fare affidamento sul tipico meccanismo di polling HTTP e, invece, SignalR utilizza il meccanismo push per rendere disponibile il nuovo contenuto ai client. Ciò consente di migliorare le prestazioni complessive dell'applicazione e l'esperienza utente.

SignalR ha un'API molto semplice che è molto facile da usare per chiamare le funzioni JavaScript lato client all'interno del browser client direttamente dal lato server. Utilizza le chiamate di procedura remota (RPC) per richiamare la comunicazione ClientServer e fornisce anche codice .NET completo per la gestione della connessione Client-Server.

SignalR gestisce la funzionalità di comunicazione completa tra server e client e non è necessario implementarla da soli. Per avere uno scambio di messaggi super veloce, in SignalR è integrato un livello di trasporto. Tutto quello che devi fare è introdurre le risorse di SignalR nell'applicazione ASP.NET e iniziare a utilizzare i suoi metodi.

Ecco un diagramma di alto livello per riferimento.

SignalR gestisce tutte le connessioni internamente e sul back-end vengono utilizzati Web Socket se supportati dal client (HTML5 e successivi). Se i Web Socket non sono disponibili, torna automaticamente al vecchio meccanismo di trasporto, ove necessario. Ciò semplifica i tuoi sforzi di sviluppo e non devi più scrivere e gestire questo codice di comunicazione da solo.

Creare il tuo primo ASP.NET SignalR Applicazioni

L'uso di SignalR nella tua applicazione è molto più semplice di quanto pensi. In questo caso, prendiamo un esempio di Chat Hub. Puoi iniziare creando un semplice progetto Web ASP.NET con l'aggiunta di SignalR. Ora, per il programma Chat Hub, puoi richiamare classi hub generiche che contengono metodi predefiniti per la comunicazione con le connessioni SignalR.

Ecco come importare il file Hub Microsoft.AspNet.SignalR class nel tuo programma di esempio che chiama un esempio broadcastMessage su tutti i client connessi.

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

Figura 2: implementazione della classe SignalR ChatHub

L'esempio seguente definisce il metodo in 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>

Figura 3: implementazione JavaScript

ASP.NET SignalR Casi d'uso

Qualsiasi applicazione ASP.NET che utilizza una funzionalità Web in tempo reale è il candidato giusto per incorporare SignalR nella sua architettura. In altre parole, questo è uno scenario in cui l'applicazione invia molti nuovi contenuti dal server al client e l'utente deve consumarli mentre i dati cambiano.

Allo stesso modo, SignalR può essere utilizzato per migliorare le prestazioni delle applicazioni che utilizzano il meccanismo di polling lungo AJAX per recuperare nuovi dati. Pertanto, non appena è presente un aggiornamento dei dati nell'applicazione ASP.NET, i metodi JavaScript lato client vengono chiamati automaticamente da SignalR per richiedere il dat. Ciò garantisce che gli aggiornamenti in tempo reale vengano inviati istantaneamente ai client Web.

Di seguito sono menzionati alcuni casi d'uso popolari per SignalR.

1. Sistemi di chat
2. Internet of Things (IoT)
3. Applicazioni di gioco
4. Sistemi di prenotazione aerea
5. Applicazioni di borsa
6. Di Più ...

Il problema: SignalR non è scalabile immediatamente

Sebbene l'implementazione della libreria SignalR nell'applicazione ASP.NET possa essere una scelta saggia, la sua incapacità di scalare linearmente può effettivamente vanificare il suo intero scopo. Ecco perché:

Poiché SignalR sta lavorando su un modello basato su socket Web, la sua distribuzione su server singolo funziona correttamente con tutti i messaggi inviati a tutti i client connessi al server Web.

Tuttavia, il singolo server può presto raggiungere la capacità in base all'aumento del carico delle richieste dell'applicazione. A questo punto, è necessario ridimensionare aggiungendo più server Web e creando una "Web Farm". Mentre lo fai, le tue richieste client vengono distribuite e quindi possono anche essere instradate a diversi server web. Un client connesso a un server Web tramite socket Web non riceverà i messaggi inviati da un altro server Web. Ciò porterà a una situazione in cui i client non riceveranno messaggi SignalR e rimarranno non sincronizzati.

Quei client in realtà aspetteranno fino a quando tale funzionalità non verrà spinta dai rispettivi server Web, il che aumenterà la latenza. Inoltre, in un'applicazione basata su più server, non è necessario che tutti i server Web richiamino i nuovi dati in entrata. Quindi, ci sono forti possibilità che questi nuovi dati non vengano inviati ai rispettivi client e che i messaggi vengano completamente persi.

Prendiamo come esempio un'applicazione del mercato azionario in tempo reale, in cui migliaia di valori azionari cambiano ogni secondo. In uno scenario del genere, i clienti finali necessitano di informazioni accurate e assolutamente corrette ogni volta che un prezzo cambia.

I mercati azionari gestiscono enormi quantità di dati di transazione elevati ed è molto importante che tutte le informazioni vengano inviate a tutti gli utenti in modo tempestivo. Avere una Web farm può causare una maggiore latenza per alcuni utenti e alcuni utenti potrebbero perdere completamente gli aggiornamenti importanti. Ciò crea un'esperienza utente scadente e avrà un impatto negativo sulla tua attività.

Per contrastare questi problemi, Microsoft offre la possibilità di utilizzare un backplane, che può essere generalmente definito come archivio centrale dei messaggi, a cui tutti i server Web sono collegati contemporaneamente.

SignalR backplane consente ai server Web di connettersi e inviare prima tutti i messaggi a se stessi invece di inviarli ai propri client connessi. Il backplane trasmette quindi questi messaggi a tutti i server Web che internano, trasmettono questi messaggi ai loro client connessi. Ciò garantisce che tutti i messaggi vengano inviati a tutti i client finali anche richiamati dal server Web a cui il client non era connesso.

SignalR backplane potrebbe essere un disco, un database, un bus di messaggi o una cache distribuita in memoria. Consentitemi di discutere le opzioni del backplane più comunemente utilizzate e i relativi problemi.

Problemi con il database relazionale come SignalR Backplane

SignalR viene utilizzato nelle applicazioni in tempo reale che gestiscono enormi volumi di dati. Il backplane deve essere in grado di gestire il carico di messaggi estremo e anche quello in modo rapido e affidabile. Il database relazionale è comunemente usato come backplane che non è molto adatto poiché il backplane deve essere di natura scalabile.

Facciamo un esempio in cui si dispone di un'applicazione di e-commerce ASP.NET distribuita su 10 server Web in una Web farm. Tutti questi 10 server Web hanno i loro client basati su browser separati ad essi collegati tramite SignalR e anche i server Web sono collegati a un backplane che in questo caso è un database.

Se uno dei server Web genera 1 messaggio ciascuno per un totale di 10 messaggi, questi 10 messaggi verranno trasmessi al backplane e il database trasmetterà quindi tutti questi messaggi a tutti i 10 server Web collegati. Ciò equivale a un massimo di 100 messaggi trasmessi dal database.

Ora immagina la stessa configurazione ma l'applicazione è notoriamente chiacchierona e i tuoi server producono un totale di 10000 messaggi (1000 messaggi per server Web) in un dato momento. Il backplane dovrà trasmettere 100000 messaggi (10000 x 10) contemporaneamente. Puoi vedere quanto è facile per il database soffocare quando il numero di richieste aumenta.

Di seguito sono riportati alcuni problemi relativi all'utilizzo dei database relazionali SignalR backplane:

1. Di solito, il carico di transazione è molto elevato ed è necessaria una consegna più rapida per escludere il fattore di latenza. I database relazionali sono lenti e possono persino soffocare sotto i picchi di carico di elaborazione dei dati in tempo reale.
2. Essendo basato su un disco, un database relazionale non può mai funzionare abbastanza velocemente da raggiungere la quantità di throughput desiderata sotto carico elevato.
3. Ancora più importante, i database relazionali mancano chiaramente della capacità di ridimensionamento lineare in cui non è possibile aggiungere più server per gestire più carico.

Problemi con Redis as SignalR Backplane

La seconda opzione può essere da usare Redis come il tuo SignalR backplane che sebbene risolve i problemi relativi alle prestazioni e alla scalabilità che si hanno con i database relazionali ma non è nemmeno una scelta adatta da fare. Ecco alcuni dei motivi alla base di questo:

• Redis è una cache distribuita basata su Linux e non è un'opzione .NET nativa. Utilizzo di un sistema basato su Linux per ASP.NET SignalR non ha molto senso dove dovrai avere lo stack Linux insieme a Windows e avrai bisogno di competenze separate per gestire e monitorare questa configurazione.
• Uno sviluppatore .NET desidera sempre uno stack .Net nativo al 100% durante lo sviluppo di tali applicazioni Web in tempo reale. Sarà controintuitivo gestire una soluzione .NET non nativa come a SignalR backplane mentre tutti gli altri moduli dell'applicazione sono .NET nativi al 100%.
• Un'altra limitazione in Redis è che la sua versione con porting di Windows .NET nella piattaforma Microsoft Azure è piena di bug secondo le recensioni degli utenti che si astengono persino Redis dall'uso della propria versione con porting di .NET Windows in Azure.

Questo rende Redis, una scelta ambivalente tra gli sviluppatori .NET dal punto di vista della compatibilità.

La soluzione: utilizzare NCache as SignalR Backplane

NCache è un sistema di cache distribuita in memoria sviluppato da Alachisoft ed è l'opzione più appropriata da utilizzare come backplane. NCache è un cluster di server cache economici che sono raggruppati insieme per fornire memoria scalabile e capacità della CPU. È essenzialmente una capacità logica di più server che viene fornita con tutte le funzionalità per essere utilizzata come server SignalR backplane.

La parte migliore dell'uso NCache come il tuo SignalR backplane è che è .NET nativo al cento per cento e non sono necessarie modifiche importanti al codice nell'applicazione ASP.NET. È come un'opzione plug-nplay che non solo ti dà la possibilità di gestire i tuoi messaggi del backplane, ma puoi anche monitorare questi messaggi usando il NCache strumenti di monitoraggio delle prestazioni.

NCache fornisce l'estensione SignalR da utilizzare come backplane nelle applicazioni ASP.NET.

Tutti i tuoi server web nella web farm sono registrati con NCache utilizzando NCache Piattaforma di messaggistica Pub/Sub. I server Web registrano un argomento specifico per i messaggi di SignalR e NCache quindi trasmette questi messaggi a tutti i Web Server. È fondamentalmente una struttura di trasmissione di messaggi a due vie in cui i tuoi editori possono essere abbonati e viceversa.

Attaccare NCache come backplane nell'applicazione basata su SignalR, devi solo introdurre una riga di codice, menzionata nella guida all'implementazione dettagliata.

Perché NCache Il backplane è migliore di SQL Server?

Per ottenere la migliore esperienza utente nella tua applicazione ASP.NET, NCache funge da backplane molto veloce, affidabile e scalabile per gestire enormi quantità di notifiche. Di seguito sono menzionati alcuni vantaggi chiave dell'utilizzo NCache invece di RDBM come backplane.

1. NCache è linearmente scalabile (alto throughput e bassa latenza)

   La caratteristica più importante di NCache backplane è che offre il massimo throughput e la latenza minima. Gestisce senza problemi grandi quantità di dati in modo rapido mantenendo tutta l'elaborazione dei messaggi in memoria, escludendo qualsiasi possibilità di aumento della latenza.

   Per consegnare tutti i messaggi in tempo, NCache offre il massimo throughput durante la trasmissione distribuendo il carico su tutti i server disponibili nel cluster di cache e consente inoltre di aggiungere più server in fase di esecuzione.

   Di seguito sono riportati alcuni numeri di benchmark delle prestazioni come riferimento.

   

   Ciò ti offre una scalabilità lineare complessiva all'interno dell'architettura dell'applicazione e non devi preoccuparti che le prestazioni dell'applicazione diminuiscano e in particolare sotto carichi estremi.

2. NCache è estremamente affidabile

   La seconda caratteristica di NCache backplane è la sua estrema affidabilità. Per garantire una consegna garantita dei messaggi, soprattutto nel caso di applicazioni mission-critical, NCache può essere utilizzato come backplane in modo da non doversi preoccupare che nessuno dei tuoi messaggi vada perso a causa di server che si interrompono o vengono interrotti per manutenzione. Mantiene il backup di ogni server cache utilizzato nel cluster per SignalR backplane che viene reso automaticamente disponibile in caso di inattività di un server.

   L'estrema affidabilità di NCache è attribuita alla sua caratteristica che trasmette tutti i messaggi a ogni server web connesso al backplane. Il backup dei tuoi dati su altri server assicura che mentre le tue applicazioni mission-critical trasferiscono carichi utili pesanti, non ci sono possibilità di perdita di dati.

3. NCache è altamente disponibile

   Un'altra caratteristica importante di NCache backplane è la sua alta disponibilità. Insieme a NCache installato come tuo SignalR backplane, il tuo sistema diventa altamente disponibile poiché i tuoi messaggi vengono ora trasferiti tramite un cluster di cache sempre attivo.

   NCache l'architettura garantisce la funzionalità di alta disponibilità attraverso il suo "cluster di cache sempre attivo" che può essere basato su una delle nostre varie topologie di memorizzazione nella cache. Ad esempio, la topologia "Partition-replica" fornisce una partizione attiva su tutti i server e ogni server ne ha un backup. Quindi, se un server si interrompe, i client lo rilevano automaticamente e eseguono il failover della connessione agli altri nodi sopravvissuti.

   Il cluster di cache di NCache è in grado di funzionare anche se solo 1 server è attivo e funzionante ed è ciò di cui hai bisogno almeno per uno scenario di uptime del cento per cento. Questa funzione si ripaga nei casi in cui i tuoi server vengono colpiti da una calamità naturale o li abbatti intenzionalmente per motivi di manutenzione. In breve, le pragmatiche topologie di memorizzazione nella cache di NCache ti aiuta a raggiungere un tempo di attività del 100% nelle tue applicazioni basate su SignalR.

   

Perché NCache è meglio che Redis?

NCache è anche meglio di Redis dal punto di vista delle caratteristiche. Per escludere tutte le carenze incontrate dagli sviluppatori in Redis sistema di cache distribuito, NCache ha queste tre caratteristiche superlative.

• .NET nativo: NCache è .NET nativo al 100% e quindi è perfetto per le applicazioni ASP.NET che utilizzano SignalR. D'altro canto, Redis proviene da uno sfondo Linux e non è una cache .NET nativa.
• Più veloce di Redis: NCache in realtà è più veloce di Redis. NCache La funzionalità Client Cache offre NCache un notevole incremento delle prestazioni.
• Altre caratteristiche: NCache offre una serie di importanti funzionalità di cache distribuita che Redis non. Vedi maggiori dettagli in questo Redis vs NCache

Implementazione NCache SignalR Backplane

Puoi distribuire NCache come il tuo SignalR Backplane con un solo cambio di riga e puoi seguire il tutorial passo dopo passo di seguito per equipaggiare le tue applicazioni per questo.

1. Installa il pacchetto NuGet

   Inizia installando il Alachisoft.NCache.Segnale R Pacchetto NuGet nell'applicazione eseguendo il comando seguente nella Console di gestione pacchetti:

   Install-Package Alachisoft.NCache.SignalR

2. Includi spazio dei nomi

   nella vostra Avvio.cs file, includi questi due spazi dei nomi come indicato di seguito:

   • Alachisoft.NCache.Segnale R
   • Microsoft.AspNet.SignalR
3. Modifica Web.config

   Nel tuo file Web.config, dovrai definire cacheName e EventKey nel etichetta:

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

   Figura 8: modifiche a Web.config

4. Registrati NCache as SignalR Backplane per la tua Applicazione

   Registra un'istanza dell'UtilizzoNCache() in Startup.cs dell'applicazione in uno dei seguenti overload:

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

   Figura 9: registrazione NCache SignalR Backplane (sovraccarico 1)

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

   Figura 10: registrazione NCache SignalR Backplane (sovraccarico 2)

Conclusione

Per concludere il tutto, NCache è essenzialmente una cache distribuita in memoria basata su .NET che può essere utilizzata in tutte le applicazioni Web ASP.NET in tempo reale come backplane per SignalR per aumentare le prestazioni dell'applicazione Web.

Le caratteristiche che lo distinguono dalle altre opzioni disponibili includono le prestazioni super veloci, il 100% di uptime, l'affidabilità dei dati, la consegna garantita dei messaggi e la capacità di mantenere il massimo throughput con la minima latenza.

Cosa fare dopo?

• NCache Dettagli
• Confronto edizione
• Scaricare NCache
• NCache vs AppFabric
• NCache vs Redis
• NCache vs Memcached