scalata ASP.NET SignalR App con cache distribuita
Webinar registrato
Kal Ali e Nick Zulfiqar
ASP.NET SignalR è una libreria open source per sviluppatori Web che viene utilizzata molto comunemente in questi giorni per aggiungere funzionalità Web in tempo reale alle applicazioni. Puoi usare ASP.NET SignalR per inviare il contenuto dal lato server a tutti i client connessi non appena le informazioni diventano disponibili.
SignalR aiuta a semplificare gli sforzi di sviluppo necessari per aggiungere funzionalità Web in tempo reale all'applicazione. Alcune applicazioni comuni che possono utilizzare SignalR sono sistemi di chat, Internet of Things (IoT), applicazioni di gioco, sistemi di prenotazione aerea, applicazioni di borsa e molti altri.
Il problema con SignalR è che non è scalabile per impostazione predefinita. Inoltre, per creare una web farm, Microsoft offre la possibilità di utilizzare un SignalR backplane che può essere generalmente definito come archivio centrale di messaggi e al quale sono collegati contemporaneamente tutti i web server. I messaggi SignalR vengono trasmessi a tutti i client finali collegati tramite il backplane.
Tipicamente, SignalR backplane è un database relazionale lento e non scalabile per gestire un carico di messaggistica estremo, requisito fondamentale per applicazioni Web in tempo reale ad alto traffico. SignalR backplane deve anche essere molto affidabile e altamente disponibile in modo da avere un tempo di attività del cento per cento sull'estremità dell'applicazione.
In questo webinar puoi vedere come NCache SignalR backplane è un'opzione migliore rispetto alle opzioni tradizionali per la distribuzione e il ridimensionamento in tempo reale ASP.NET SignalR applicazioni web con backplane. Dimostriamo come NCache può essere usato come tuo SignalR backplane senza richiedere alcuna codifica importante.
Il nostro Senior Solutions Architect copre:
- Introduzione alla ASP.NET SignalR e i suoi casi d'uso comuni
- Problemi con il ridimensionamento delle app SignalR e con le tradizionali opzioni del backplane
- Perché NCache Il backplane è un'opzione migliore in confronto
- utilizzando NCache come backplane per le tue applicazioni ASP.NET
- NCache Pacchetti Nuget per SignalR backplane
- Crea, distribuisci ed esegui app SignalR utilizzando NCache backplane
Quindi, oggi parleremo di SignalR come tecnologia, come e dove è possibile candidarsi per essere utilizzata all'interno delle vostre applicazioni e quali sono i problemi che si riscontrano in particolare, nel caso in cui si introduca il Backplane in questo scenario e come cosa sono le possibili opzioni che hai e come puoi sostanzialmente aggirarle? Quindi, tratterò tutte queste diverse cose e come prodotto di esempio, userò NCache. Quindi, arriveremo a quella parte più avanti, inizialmente tratteremo solo alcune teorie di base lì.
Introduzione a SignalR
Quindi, passiamo all'effettiva introduzione a SignalR. Quindi, queste sono alcune definizioni che ho copiato dalla documentazione Microsoft. Così, cos'è SignalR? SignalR è fondamentalmente una libreria open source che gli sviluppatori possono utilizzare per introdurre funzionalità Web in tempo reale all'interno delle applicazioni ASP.NET. Quindi, lascia che ti dia un esempio per spiegare come e cosa intendo esattamente qui. Ad esempio, hai un utente che sta accedendo a una pagina web e lui o lei ha un certo bit di dati, che è presente nella pagina ma se quei dati devono essere aggiornati o se l'utente vuole ottenere dati aggiornati in scenari normali , l'utente deve aggiornare la pagina, in pratica l'utente deve inviare una richiesta e quindi in risposta a ciò vengono ricevuti i dati aggiornati, o questo o deve esserci una lunga attesa che deve essere implementata nella parte posteriore. Ma se si dispone di SignalR, questo non sarebbe necessario e parlerò di questi dettagli in seguito e questo è uno degli ottimi casi d'uso in cui SignalR è un ottimo candidato.
Quindi, in secondo luogo, SignalR ti dà la possibilità di avere diversi contenuti push di codice direttamente sul lato client. Quindi, in pratica, la parte in cui il cliente deve inviare una richiesta per ottenere i dati aggiornati è che non è più necessario essere presenti. Quindi, in pratica, siete i client, tutti i client effettivamente collegati al server web verrebbero aggiornati non appena ci fossero nuovi dati all'interno del server. Pertanto, il server non deve attendere che il client richieda effettivamente nuovi dati. I dati verrebbero aggiornati automaticamente sul client. Quindi, la cosa migliore di SignalR è che ti espone la funzionalità. Quindi, devi solo introdurre le risorse di SignalR all'interno della tua applicazione e devi chiamare alcune funzioni specifiche e tutto il resto è gestito da SignalR. Quindi, la tua applicazione utilizzerebbe SignalR per inviare un messaggio, ad esempio, dai client al servizio e dai server al client, qualunque sia il tuo scenario e tutto il resto e con tutto il resto, intendo il livello di trasporto. Il modo in cui il messaggio viene trasferito e il modo in cui viene notificato, tutto il resto è gestito dalla logica SignalR. Quindi, non è necessario farlo all'interno della tua applicazione, devi solo introdurre queste API all'interno della tua applicazione e tutto il resto viene gestito automaticamente da SignalR. Quindi, in questo diagramma se puoi vedere proprio qui.
Ti faccio solo un esempio. Quindi, in SignalR c'è un concetto di Hub. Quindi, in questo diagramma proprio qui, possiamo vedere che il server, questo è un server web e questo è un client connesso. Può essere un client HTML o JavaScript. Quindi, questo server è in grado di chiamare questa funzione myClientFunc() sul client proprio qui e viceversa. Se guardi questo diagramma.
Il client è in grado di chiamare questa funzione specifica myServerFunc() sul lato server. Quindi, fondamentalmente con HTTP sappiamo tutti che è un protocollo senza stato. C'è una richiesta e poi c'è una risposta e non c'è nient'altro, rimane tutto il resto viene rimosso ma con SignalR quello che succede è che sotto SignalR usa WebSocket per mantenere le connessioni. Quindi, questi sono per le tecnologie più recenti ma in quelle più vecchie lì, usano il normale in quelle di base ma usa il concetto di WebSocket a cui è in grado di invocare funzioni sia dal server al client e quindi dal client al server dipende da come è fatto.
Quindi, lascia che ti spieghi alcuni casi d'uso generali per SignalR. Quindi, il primo è un sistema di chat. Questo è anche un progetto di esempio condiviso dalla stessa Microsoft e anche nella mia dimostrazione utilizzerò un sistema di chat fornito da Microsoft e avrò NCache integrato con esso, ma torniamo agli esempi qui. Quindi, qui hai bisogno di messaggi in tempo reale che devono essere inviati, ad esempio, se hai un gruppo in cui è presente un numero di membri all'interno del gruppo e se uno qualsiasi dei membri invia un messaggio, la notifica del messaggio deve essere ricevuta da tutti i membri del gruppo e deve essere fatto istantaneamente. C'è un ritardo di alcun tipo che non può essere concesso e lo stesso caso con l'industria dei giochi. Quindi, ad esempio, hai giochi multiplayer online in cui è necessario riflettere molto perché ci sono molti giocatori che giocano alla fine della stessa sessione insieme e i dettagli del gioco devono essere sincronizzati con tutti loro .
Il terzo caso d'uso è, ad esempio, il sistema di prenotazione aerea. Quindi, se è stato prenotato un biglietto o un posto specifico, tutte le altre persone o tutti gli altri utenti, che stanno attualmente visualizzando quei dati specifici, devono essere avvisati che questo specifico biglietto o questo specifico posto è già prenotato e non può essere prenotato più.
Esempi simili di azioni perché se cambiano costantemente i valori salgono e scendono. Quindi, devono essere aggiornati sul lato client abbastanza rapidamente ed è davvero un ottimo requisito.
Un altro è il contenuto del secondo schermo, che può essere pubblicità o qualsiasi altro tipo di notifica che deve essere mostrato e infine c'è l'Internet dei dispositivi, l'Internet delle cose. Quindi, in pratica, questi dispositivi raccolgono costantemente alcuni dati, li analizzano, lanciano alcune notifiche. Quindi, tutte queste cose richiedono un certo tipo di affidabilità e c'è l'urgenza che queste vengano ricevute dai ricevitori. Quindi, tutti questi casi d'uso sono scenari piuttosto buoni in cui è possibile utilizzare SignalR e in generale se si parla di oggi, viene effettivamente utilizzato proprio ora.
Quindi, se potessi passare alla diapositiva successiva. Ragazzi, se avete domande potete sempre entrare e Nick mi farebbe sapere se c'è una domanda e sarò felice di rispondervi.
Ridimensionamento delle applicazioni SignalR
Quindi, parliamo del ridimensionamento delle app SignalR. Quindi, se guardi questo esempio proprio qui.
Questo esempio mostra fondamentalmente che hai una web farm e potresti anche essere un web garden, ma sto dando l'esempio con la web farm. Quindi, hai una web farm qui, dove hai il numero di server web qui, hai un bilanciamento del carico tra il quale riguarda tutte le richieste, che stanno arrivando a tutti i server web che sono presenti all'interno della tua web farm e quindi hai tutti questi diversi clienti. Questi client sarebbero collegati a uno qualsiasi dei server Web all'interno della Web farm.
Quindi, se prendi questo esempio qui, il client A è connesso a questo server web e il client B è connesso a questo server web e il client C è connesso a questo server web. Quindi, il problema qui è che, ad esempio, se questo server Web deve inviare un messaggio, deve inviare qualsiasi tipo di messaggio o notifica. Sarà in grado di inviare quella notifica solo ai suoi specifici client connessi e in questo caso, se questo client A sta inviando un messaggio, verrebbe ricevuto solo dai client collegati a questo server web e in questo caso è solo uno.
Quindi, cosa accadrebbe se ci fosse una chat di gruppo e fosse in corso tra almeno tre client e fossero collegati a tre diversi server web. Quindi, se uno dei client invia un messaggio, gli altri client sarebbero ora in grado di ricevere questo messaggio in questo scenario specifico perché solo i client connessi a un server Web specifico sarebbero in grado di ricevere quella notifica. Quindi, in questo caso, è limitato al fatto che solo i client collegati al server web possono ricevere questa notifica e per sbarazzarsene SignalR ha introdotto un termine con il nome SignalR Backplane.
SignalR Backplane
Lascia che ti spieghi di cosa si tratta esattamente. Quindi, se prendi lo stesso esempio ma un po' diverso di uno scenario diverso, hai una web farm proprio qui e hai un sistema di bilanciamento del carico in mezzo, supponiamo che tutte le richieste del client arrivino attraverso quel bilanciamento del carico e arrivando al rispettivo servizio web.
Quindi, in questo caso proprio qui, c'è un bus condiviso, c'è un repository condiviso che è connesso a tutti i server web presenti all'interno del modulo proprio qui. Quindi, se assumiamo di avere dieci server Web e tutti sarebbero effettivamente collegati a questo backplane proprio qui e questo è il luogo comune che verrà utilizzato per inviare o, in pratica, trasmettere i messaggi o qualsiasi notifica a tutti i server web collegati.
Quindi, in questo caso, se questo server web sta generando una notifica o un messaggio, non verrà inviato direttamente ai client collegati. In realtà lo invierebbe prima al backplane e una volta che il backplane riceve questa notifica o messaggio, lo invierà a tutti i server Web collegati e quindi i server Web li invieranno ai loro client connessi e in questo in questo modo, garantisce che il messaggio o la notifica non sia limitato ai soli client connessi di quello specifico server web. Viene ricevuto da tutti i client collegati a quella specifica web farm, ad esempio a destra. Quindi, procediamo passo dopo passo.
Quindi, ad esempio, c'era una notifica che questo server web doveva inviare. Quindi, la prima cosa che farà è notificare al Backplane proprio qui e ciò che il Backplane farà proprio qui, lo trasmetterà a tutti i server Web collegati proprio qui. Quindi, il primo messaggio ricevuto dal backplane e poi il backplane lo ha inviato al server uno e poi al server due proprio qui e poi questi due in questi server Web specifici, hanno inviato quel messaggio a tutti i client connessi nel loro scenario.
Quindi, in questo caso, a differenza dello scenario che era qui, se ad esempio c'è una chat di gruppo in corso come ho detto prima, tutti questi client non otterrebbero un'esperienza o una vista coerenti ma in questo caso proprio qui, se c'è un gruppo chat in corso, tutti i client avrebbero una visione coerente, sarebbero stati informati istantaneamente di qualsiasi aggiornamento o nuovo messaggio in arrivo. Quindi, questo è uno dei principali vantaggi dell'introduzione di un backplane nello scenario, ma ora stiamo andando per vedere quali sono i limiti che sono stati visti con uno scenario Backplane e quali sono le possibili opzioni che potremmo avere?
Colli di bottiglia con SignalR Backplane
Bene. Quindi, stavo menzionando i colli di bottiglia con SignalR Backplane. Quindi, questi sono i principali colli di bottiglia che si vedono all'interno del SignalR Backplane e queste sono anche le opportunità che ogni possibile candidato può contrassegnare per essere utilizzato come a SignalR Backplane nello scenario SignalR.
Latenza e throughput
Quindi, il primo è la latenza e il throughput. SignalR Backplane deve avere una latenza molto bassa e un throughput elevato e lasciami spiegare, cosa significa bassa latenza? La latenza in pratica, significa il tempo che SignalR Backplane o Backplane impiega per elaborare un messaggio una volta ricevuto, il tempo necessario per elaborare quel messaggio e quindi trasmetterlo o inviarlo a tutti i servizi Web connessi in questo scenario, ovvero la latenza.
Quindi, in pratica, deve essere molto minimo, ciò significa che non appena riceve un messaggio, deve inviarlo rapidamente a tutti i server Web connessi nella Web farm. Ad esempio, e quindi il throughput è il numero totale di messaggi, che può fare in un determinato intervallo di tempo e può essere di un secondo, dieci secondi o addirittura cento secondi a seconda della scala di misurazione qui presente.
Di solito nelle applicazioni dell'ambiente di distribuzione in loco, questi database sono presenti nel loro backplane, ma ci sono alcune limitazioni con il database. I database sono generalmente lenti, non sono in grado di scalare in orizzontale e di solito sono soffocati da un carico di transazioni elevato. Quindi, sono lenti e quindi non sono in grado di scalare verso l'esterno perché è un singolo server e poi c'è un backup, ad esempio, se questo è uno scenario ma è un singolo server e c'è un certo limite al quale solo può elaborare il numero delle richieste che arrivano dopo, che inizierà a essere sopraffatto da queste notifiche dalle transazioni e inizierebbe effettivamente a influenzare la tua applicazione. Quindi, puoi sostanzialmente ridimensionare il numero di server Web all'interno del tuo ambiente per gestire il carico crescente in arrivo sul tuo modulo Web, ma quando quelle applicazioni devono entrare in contatto con un database. Ad esempio, nella banca è lì che si trova il collo di bottiglia ed è lì che tutte le tue applicazioni subiscono un colpo sulla parte delle prestazioni.
Consegna garantita dei messaggi
La prossima cosa è la consegna garantita dei tuoi messaggi. SignalR Backplane deve essere affidabile, deve garantire una consegna garantita dei messaggi. Non dovrebbe esserci uno scenario in cui un messaggio non è stato consegnato tutto è stato perso o a causa di qualsiasi scenario non è mai stato ricevuto correttamente. Quindi, deve avere una consegna garantita dei messaggi.
Un altro sono i database, come ho detto in precedenza, il database può soffocare sotto carico estremo ed è anche presente un singolo punto di errore. Quindi, se quel server specifico si interrompe fondamentalmente nell'intero ambiente, non dovrebbe essere lo scenario, dovrebbe esserci una sorta di backup efficiente che può in uno scenario di emergenza qualunque scenario dovrebbe essere in grado di recuperare molto rapidamente da quello scenario specifico.
Alta disponibilità del backplane
Il terzo è che deve avere un'elevata disponibilità. Quindi, SignalR deve essere altamente disponibile a causa di qualsiasi scenario, se c'è qualche tipo di problema l'intero sistema dovrebbe ora andare in crash. Dovrebbe esserci una sorta di backup che può aiutare a continuare le operazioni, non dovrebbe essere influenzato molto rapidamente se si verifica una situazione. Ci dovrebbe essere una sorta di backup e che dovrebbe essere in grado di mantenere tutto o mantenere l'ambiente in funzione fino a quando tutto può essere riportato alla normalità e questo può essere in scenari pianificati, dove c'è una sorta di scenario di manutenzione pianificato o non pianificato in cui qualsiasi cosa potrebbe andare storto.
Quindi, se guardiamo questo diagramma proprio qui.
Possiamo esaminare il collo di bottiglia della scalabilità con un database ed è esattamente quello che vi stavo spiegando proprio ora qui, avete tutti i vostri clienti collegati e le loro richieste vengono reindirizzate tramite il sistema di bilanciamento del carico e questa è la vostra web farming . Come accennato in precedenza, puoi ridimensionare questa web farm, puoi aumentare il numero di server Web e ciò a sua volta aumenterebbe il numero totale di richieste, che il tuo ambiente può sostanzialmente richiedere in un unico momento, ma il problema reale si basa, quando questi server Web devono entrare in contatto con il back-end con il database sul retro e potrebbe essere per qualsiasi scenario, ma non solo per SignalR o anche per qualsiasi altro scenario.
Cache distribuita in memoria come SignalR Backplane
Quindi, ho intenzione di presentare la soluzione. La soluzione a questo è una cache distribuita in memoria come a SignalR Backplane e come accennato all'inizio, sarò usato NCache come prodotto di esempio per quello e NCache è un prodotto open source. Abbiamo diverse versioni e puoi valutarle se necessario.
Cluster di server cache
Quindi, lascia che ti spieghi cos'è una cache distribuita in memoria? Quindi, fondamentalmente, la cache distribuita in memoria è un cluster di server cache economici. Quindi, hai diversi server di cache che ospitano la stessa cache, logicamente è una singola unità ma sotto ci sono più server, che ospitano questa cache e una volta che sono insieme vogliono un numero multiplo di server. Non solo stanno raccogliendo le risorse di potenza computazionale totale, ma stanno anche attirando le risorse di memoria. Quindi, poiché avevi il numero di server, fondamentalmente aumenta il numero di transazioni che possono essere eseguite in un determinato periodo di tempo e anche il numero totale di dati che possono essere archiviati.
In questo momento, sto spiegando in generale in termini di cos'è una cache distribuita in memoria? Non sto parlando in riferimento a SignalR ma mapperò tutte queste funzionalità con i colli di bottiglia che sono stati inizialmente discussi. Quindi, inizialmente sto solo spiegando e questa potrebbe essere una cache distribuita che potrebbe essere utilizzata per uno scenario di memorizzazione nella cache di oggetti o uno scenario di memorizzazione nella cache di sessione, è per tutti quelli in questo momento, ma mapperò anche queste funzionalità laggiù.
Cache sincronizzata tra i server
Quindi, qui più server multipli raggruppano il pool nelle loro risorse di memoria e anche le risorse di potenza di calcolo insieme e la cosa successiva è una cache sincronizzata attraverso il servizio. Quindi, con riferimento a NCache quello che fa è anche se, ad esempio, hai quattro server cache che ospitano la stessa cache e ci sono alcuni nuovi dati che vengono aggiunti alla cache. C'è una mappa di distribuzione che viene aggiornata non appena i dati vengono aggiunti o aggiornati o addirittura rimossi, vengono aggiornati.
Quindi, in qualsiasi momento, anche se uno dei server, uno dei server cache riceve un nuovo elemento aggiunto, tutti gli altri server all'interno del cluster verrebbero automaticamente e istantaneamente informati che c'è un nuovo elemento aggiunto alla cache ora . Quindi, garantisce che l'intero ambiente rimanga sincronizzato tra loro e che ci siano diverse topologie in cui i dati vengono mantenuti all'interno della cache e questa è una discussione separata, ma generalmente parlando non appena l'elemento viene aggiunto, tutti i server nel cluster ottengono notificato di un nuovo elemento che viene aggiunto. Quindi, in questo modo garantisce che sia immediatamente visibile a tutti i server presenti all'interno dello stesso costume.
Scalabilità lineare
Il terzo è linearmente scalabile come ti ho detto prima, si tratta di un numero multiplo di server che vengono messi insieme e non c'è limite a cui puoi aggiungere tutti i server qui, quanti sono necessari e la cache si regolerebbe automaticamente. In pratica aumenta la richiesta totale che può gestire, aumenta anche il numero totale di dati dei membri che possono essere aggiunti alla stessa cache. Quindi, è tutto linearmente scalabile. Quindi, quando si ridimensiona il livello dell'applicazione, è anche possibile ridimensionare il livello di memorizzazione nella cache e questo era uno dei colli di bottiglia con i database. Non puoi mai ridimensionare il tuo ambiente di database, ma con questo puoi sicuramente ridimensionare il tuo server cache, l'intera cache e in questo modo puoi effettivamente aumentare le prestazioni delle tue applicazioni.
Replica dei dati per l'affidabilità
Il quarto è la replica dei dati per l'affidabilità. Quindi, come ti ho detto prima, si tratta di più numeri, più server che vengono messi insieme. Quindi, a seconda della topologia, ci sono repliche mantenute su altri server. Quindi, anche se uno dei server si interrompe, i dati di quel server perso vengono replicati su uno qualsiasi degli altri server e ciò avvierà automaticamente il processo di ripristino, quindi riporterà quei dati e li rimetterebbe in le partizioni attive della cache. Se stiamo parlando di partizione di repliche, ad esempio, come topologia di NCache. Quindi, porterebbe automaticamente quei dati e li aggiungerebbe alla stessa cache. Quindi, i dati non vengono persi anche se uno dei server è sparito e se ci sono client collegati a quel server, che è stato perso, lo rileverebbero automaticamente e farebbero il failover della loro connessione al servizio rimanente presente all'interno del cluster e questo è una delle altre cose chiave, che non è un singolo punto di errore. Quindi, se hai più server finché hai un server cache rimanente nel cluster, la tua cache sarebbe funzionante, risponderesti alle richieste che stanno arrivando quindi, anche se uno dei server si interrompe, l'intero la cache non va giù. Il tuo ambiente non si interrompe e le tue applicazioni continuano a funzionare correttamente. Quindi, ora mapperò tutte queste cose di cui ho appena discusso o i colli di bottiglia che sono stati discussi in precedenza per un SignalR Backplane.
Quindi, se vai qui e il primo è stato la latenza e il throughput. Quindi, la latenza come ho detto prima è la quantità di tempo di elaborazione. Quindi, se hai molti server che generano molti messaggi e così, quelle richieste arrivano direttamente al backplane e il backplane in questo caso è Ncache. Quindi, se ritieni che il tuo ambiente sia soffocato, puoi aggiungere il numero di server e ciò aumenterebbe effettivamente la capacità totale di gestire quel numero di richieste.
Posso avere una domanda qui? Quanto è complesso da configurare NCache as SignalR Backplane? È abbastanza facile e abbiamo una spiegazione molto dettagliata e spiegata di un documento, che ti aiuta a risolverlo e affronterò esattamente questo e la parte demo pratica e mi riferirò a questa domanda lì.
Quindi, tornando ai colli di bottiglia che erano generalmente osservati con il SignalR Backplane e mappatura NCache su una funzionalità cache di disabilità generale su di esso. Quindi, come accennato in precedenza, la tua latenza diventa molto bassa poiché hai più server, che possono effettivamente gestire le richieste che stanno arrivando. Quindi, ciò ridurrebbe automaticamente la latenza e ovviamente aumenteresti anche il throughput mentre tu hanno una bassa latenza, il throughput è diminuito automaticamente e in generale le prestazioni complessive sarebbero diminuite.
Il secondo è la consegna garantita dei messaggi. Quindi, all'interno del NCache algoritmo e logica client-server, ci sono molti controlli in corso di manutenzione. Quindi, se, ad esempio, il client tenta di connettersi alla cache del cluster e se per qualsiasi motivo non è in grado di recapitare quel messaggio, ci sono tentativi interni che vengono implementati. Quindi, il cliente NCache il client tenta automaticamente di riconnettersi al server cache e questo è tutto configurabile in quanto puoi configurare il numero di tentativi, puoi configurare, per quanto tempo dovrebbe riprovare tutti quelli? Quindi, in pratica puoi assicurarti che il tuo client sia in grado di connettersi al tuo cluster di cache specifico in questo caso e anche mentre una connessione è già mantenuta e risulta interrotta. Ancora una volta, in quello scenario specifico, assicurerebbe che il messaggio venga effettivamente recapitato.
Il terzo è l'elevata disponibilità del backplane e questa è una delle cose chiave, inizialmente menzionato, hai più server che ospitano la cache. Quindi, se uno dei server si interrompe, non significa che l'intera cache si interrompa. Gli altri tuoi server saranno in grado di gestire il carico in arrivo. Avranno le connessioni dei client failover ai server rimanenti presenti all'interno del cluster. Pertanto, in questo modo garantisce un'elevata disponibilità, assicura che i messaggi vengano effettivamente recapitati e, infine, garantisce che le prestazioni siano notevolmente aumentate man mano che si aggiunge il numero, man mano che si aumenta il livello dell'applicazione. Puoi anche aumentare il livello di memorizzazione nella cache.
Kal un'altra domanda, quanto miglioramento delle prestazioni può ottenere ogni utilizzo NCache as SignalR Backplane, rispetto ai database o ci sono benchmark? Va bene in particolare per SignalR, potrei dover cercare questi benchmark ma in generale, in termini di benchmark, in termini di numero di transazioni che vengono eseguite, posso sicuramente mostrarle in seguito, c'era uno screenshot. Quindi, posso mostrarlo.
Proprio qui. Quindi, questi sono i numeri di scalabilità e sono anche specifici delle topologie, ma generalmente sono una sola volta. Quindi, poiché avevi un certo numero di server, aumenti effettivamente il numero totale di transazioni che possono essere eseguite e le transazioni suddivise in letture e scritture al secondo. Quindi, questi possono sicuramente essere confrontati con i database perché non sono scalabili. Quindi, diventerebbero un momento in cui la cache verrebbe effettivamente visualizzata rispetto al database.
Bene. Quindi, venendo qui. Questa è una distribuzione tipica di Ncache.
Quindi, ti consigliamo di avere un livello di memorizzazione nella cache separato, come puoi vedere in questo, ma puoi anche avere la cache sugli stessi server della tua applicazione. Quindi, anche questo è supportato, ma ti consigliamo di avere un livello di memorizzazione nella cache separato e darò un referral parlando in riferimento a quello, quindi questo è il tuo livello dell'applicazione, dove hai tutti i tuoi server delle applicazioni e questo è il tuo livello di memorizzazione nella cache . Ancora una volta, è linearmente scalabile, puoi aggiungere tutti i server qui necessari e quindi tutti questi server come ho detto prima, non richiedevano alcun hardware specifico. Non richiedono alta tecnologia o sono server economici e con NCache l'unico pre-record di NCache è .NET 4.0, altrimenti NCache è supportato su tutti gli ambienti Windows. I sistemi operativi consigliati sono Windows Server 2008, 12 e 16 dove qualsiasi abbia .NET 4.0 con esso, puoi sicuramente lavorarci con NCache.
Esistono due diversi tipi di installazione. c'è il NCache installazione del server cache, che può effettivamente ospitare una cache e poi c'è un remote client installazione. Remote client possono avere una cache locale o sostanzialmente autonoma e possono, hanno le librerie e le risorse per consentire ai client di connettersi alle cache del cluster remote e, come accennato in precedenza, le cache del cluster sono quelle che sono ospitate sull'installazione del server di cache . Quindi, questa è una distribuzione tipica, tutte le tue applicazioni sono connesse al database al livello di memorizzazione nella cache e anche il livello di cache è connesso al database sul retro. Abbiamo funzionalità, che è anche supportata e può essere utilizzata. Così, NCache non solo può essere utilizzato, ad esempio, come backplane per SignalR, ma può essere utilizzato per la memorizzazione nella cache dei dati, la memorizzazione nella cache della sessione e abbiamo altri webinar e documentazione, che ti aiutano a configurarli se è interessato a questo.
Bene. Quindi, ora questo diagramma mostra sostanzialmente NCache, viene distribuito come a SignalR Backplane.
Quindi, è abbastanza simile allo stesso, che stavamo inizialmente guardando. Quindi, questa è la tua web farm proprio qui e supponiamo un bilanciatore di carico qui. Quindi, tutte le richieste del cliente vengono reindirizzate, quindi invece di un backplane aereo proprio qui, NCache è usato come backplane proprio qui e hai un numero di server qui, che sono linearmente scalabili come ho detto prima in questo caso. Abbiamo tre server web, tre server cache proprio qui. Quindi, in questo caso questo server web proprio qui, ha generato una notifica o un messaggio e ha inviato questa notifica al Backplane e in questo caso il Backplane è stato NCache. Che cosa NCache farebbe? A sua volta lo pubblicherebbe sostanzialmente, trasmetterebbe questa notifica a tutti gli abbonati di questo stesso messaggio proprio qui. Quindi, una volta che questo messaggio è stato ricevuto da NCache, è stato poi trasmesso a tutti i server web collegati. In questo caso e successivamente è stato poi inviato a tutti i client collegati. Quindi, in questo modo si è assicurato che lo fosse, che tutti i client connessi avessero quel visualizzatore coerente e un'esperienza mentre lavoravano sulla loro applicazione e NCache è stato collegato come backplane in questo caso. E questi sono i numeri, di cui ho già parlato. Quindi, poiché in pratica avevi un certo numero di server, puoi vedere che c'è un miglioramento lineare nel numero di letture e nel numero di scritture che vengono eseguite in questo momento. Quindi, è linearmente scalabile, non ci si può fermare, quindi puoi aggiungere tutti i server qui necessari all'interno del tuo ambiente.
Mani sulla demo
Quindi, andrò alla parte demo pratica effettiva ed è qui che dimostrerò come creare una cache? Lo esaminerò rapidamente perché non fa parte dell'agenda, ma abbiamo altri webinar in cui trattiamo ogni singolo dettaglio e parliamo delle migliori pratiche e di altri consigli generali, quando sei creazione della cache o configurazione e configurazione di impostazioni diverse relative al processo di creazione della cache.
Installazione NCache e creare una cache raggruppata
Quindi, la prima cosa che devi fare è installarla, completarla e scaricarne una copia NCache dal nostro sito Web e quindi è necessario installarlo nel proprio ambiente. Ho due macchine, che hanno NCache già installato su di loro e lo userò. Quindi, ho intenzione di accedere a quelli. Li ho registrati in demo1 e demo2 proprio qui. Quindi, con NCache arriva uno strumento NCache manager attraverso il quale puoi sostanzialmente creare e configurare e lavorare con e gestire le cache in pratica, quindi questo è quando apri il file NCache gestore. Questa è la vista che ottieni, se fai clic con il pulsante destro del mouse sulle cache in cluster e fai clic su crea nuova cache in cluster, questa è la vista che ottieni.
Quindi, tutte le cache devono essere nominate. Vado avanti e gli darò un nome SignalRCache. Tutte le cache devono essere nominate come ho detto prima, ma questo non fa distinzione tra maiuscole e minuscole, puoi usarlo in qualsiasi modo. Fare clic su Avanti. Questi sono i quattro topologie e lo abbiamo trattato in altri webinar.
Questa è una strategia applicativa, manterrò tutto predefinito e configurerò solo i due server cache che ti ho appena mostrato, demo1 e demo2 proprio qui, facendo semplicemente clic su Avanti. Questa è la porta su cui comunica il cluster. Così, NCache utilizza le porte TCP/IP per mantenere le sue connessioni. Quindi, sto solo cercando Nestor, questa è la dimensione della cache. Se stai usando NCache per SignalR e come BackPlane per SignalR, non importa la dimensione perché è solo una coda, che verrà mantenuta all'interno della cache e non appena quel messaggio viene inviato ai client connessi verrà rimosso. Quindi, oltre a un singolo elemento non c'è nient'altro che verrà archiviato nella cache e il singolo elemento, ne parlerò più avanti quando guarderò il campione reale che viene fornito con esso.
Quindi, manterrò tutto predefinito qui, disattiverò Sfratti perché non voglio che nulla venga rimosso, anche nel caso in cui la cache si riempia. Spunterò questa casella che avvierà la cache quando faccio clic su Fine, farò semplicemente clic su Fine. Quindi, è così facile creare una cache all'interno del tuo ambiente utilizzando NCache. Quindi, aspetterò che la cache si avvii e poi aggiungerò a remote client ad esso, quella sarà la mia macchina personale proprio qui. Ok, quindi, la cache è avviata e possiamo vedere proprio qui, questa attività zero in corso a questo punto, ma è perché non abbiamo altre applicazioni, nessuna applicazione sostanzialmente connessa a questa cache in questo momento.
Quindi, andrò avanti e aggiungerò la mia macchina come nodo client ad essa per aggiungere un client o semplicemente fare clic con il pulsante destro del mouse qui e fare clic su aggiungi nodo. Gli darò l'IP della mia macchina personale, può essere un nome di macchina o un IP, entrambi sono supportati. Basta fare clic su Fine proprio qui.
Possiamo vedere che la mia macchina è stata aggiunta come a remote client giusto qui. Quindi, testerò rapidamente questa cache per vedere se tutto funziona, in realtà prima va bene, lascia che ti mostri il strumento di monitoraggio di NCache. Quindi, se stai usando NCache come backplane, puoi usare lo strumento di monitoraggio che è uno strumento eccellente, che ti dà un bel po' di dettagli su cosa sta succedendo esattamente nella cache ti aiuta a eseguire il debug dei problemi e in realtà ottieni molti dettagli su come le prestazioni sta succedendo e come da dove e dove vengono presi i colpi effettivi e cosa può essere migliorato in generale. Quindi, se faccio clic con il pulsante destro del mouse sul nome della cache proprio qui, posso fare clic sul cluster di monitoraggio. Questo si apre NCache monitore, che può essere utilizzato per monitorare la cache. Quindi, ti mostra un sacco di cose diverse proprio qui, se apri la dashboard del server proprio qui, mi dà una visione abbastanza buona di esattamente cosa sta succedendo nella cache, grafico diverso, questo è il grafico della CPU, questo è la rete totale che viene utilizzata, questa è la dimensione della cache, questo è il totale delle richieste che stanno arrivando. Quindi, ti mostra un bel po' di cose diverse che possono essere usate e guardate quando hai un ambiente di lavoro giusto qui e quello che farò è, dalla mia casella personale proprio qui. Eseguirò solo un'applicazione dello strumento StressTest per simulare un carico fittizio sulla cache. Questo strumento viene installato con NCache. Quindi, lo cercherò. Digiterò semplicemente STR, verrà visualizzato lo strumento StressTest.
Quindi, Kal mentre estrai i dati, puoi rispondere a che tipo di mainframe NCache utilizza per SignalR? Bene. Quindi in poche parole NCache sta usando il Modello Pub/Sub. Quindi, tutti questi client che sono fondamentalmente server web, sono collegati sia come editori che come abbonati. Quindi, qualsiasi client può effettivamente pubblicare un messaggio e tutti i client collegati sono anche abbonati. Quindi, riceveranno anche una notifica a riguardo. Quindi, fondamentalmente è il modello Pub/Sub, abbiamo un'API implementata separata completa così come l'intero framework di solo Pub/Sub ma sotto SignalR Pub/Sub viene utilizzato puoi usarlo anche separatamente.
Aggiungi dati di esempio e monitora la cache
Bene. Quindi, aprirò lo strumento StressTest. Quindi, questa è la posizione, dove si trova effettivamente, è a C:\file di programma\NCache\bin\strumenti quindi, cerchiamo solo uno strumento StressTest proprio qui, semplicemente aprendo l'istanza dal prompt dei comandi, lo trascinerà qui. Va bene, in realtà, ho premuto invio troppo velocemente solo per cancellare lo schermo. Va bene, quello che farò è, scriverò ok, questo è lo strumento StressTest. Darò uno spazio per dare il nome della cache, il nome della cache era signalrcache. Adesso premo invio. Quindi, se torno a questo punto di vista qui e apro le statistiche, dovremmo vedere le richieste in arrivo e farlo subito. Ok, vedi alcune richieste in arrivo ora e proprio qui, puoi vedere che ci sono un sacco di richieste diverse in arrivo sia sui server di cache collegati che su entrambi i server di cache in questo momento. Quindi, sembra che tutto funzioni davvero bene e stia accettando anche una richiesta. Se apri lo strumento di monitoraggio proprio qui, puoi vedere che questo client si è connesso qui, un client è connesso qui e se guardiamo qui, vediamo che c'è un grande salto nel numero totale di richieste in arrivo, tu può anche vedere che anche il grafico della memoria sta subendo un po' di colpi.
Quindi, se verificassimo effettivamente che funziona. Quindi, ora interromperò questo strumento, tornerò al NCache gestore. Farò clic con il pulsante destro del mouse qui. Ho intenzione di chiarire il contenuto di questo.
Esegui l'esempio di chat di SignalR
Quindi, ora che abbiamo impostato una cache e funziona perfettamente, l'abbiamo testata, sembra funzionare bene. Quindi, quello che ho intenzione di fare è aprire un progetto di esempio che viene installato sul file NCache e seguirò passo passo la documentazione, pubblicata sul nostro sito web, su come sostanzialmente configurarla. Puoi configurarlo, la tua applicazione ASP.NET da usare NCache come backplane. Quindi, se torno subito nella directory di installazione di NCache che è in c:\programmi\ncache proprio qui, posso andare nella cartella dei campioni e poi in dotnet e proprio qui, se cerchiamo solo qui, possiamo vedere che c'è un esempio di SignalRChat fornito qui. Quindi, questo viene installato con NCache e questo è proprio lo stesso, che userò nella mia dimostrazione proprio lì. L'ho già aperto proprio qui. Quindi, aprirò la documentazione e questa è la documentazione che ti offre una visione dettagliata di come puoi configurarla all'interno del tuo ambiente specifico.
Quindi, se andiamo proprio qui. Quindi, la prima cosa che devi fare è installare il file Pacchetto NuGet e lascia che ti mostri esattamente di quale pacchetto NuGet stiamo parlando. Quindi, se facciamo semplicemente clic con il pulsante destro del mouse qui e facciamo clic su gestisci i pacchetti NuGet per la soluzione. Va bene qui, se entriamo nel browser e stiamo navigando su nuget.org. Sto solo andando a cercare NCache, ok e proprio qui, se scendi un po ', penso che potrei averlo perso ma è la community SignalR, ok non c'è tempo, quindi posso trovarlo, il nome del pacchetto NuGet è Alachisoft.NCache.Segnale R. Quindi, dovrebbe venire qui, Alachisoft.NCache.Segnale R. Quindi, questo deve essere installato all'interno della tua applicazione. Non ho bisogno di installarlo a questo punto perché ho un'installazione di NCache e hai già riferimenti che richiederanno librerie ma se non stai utilizzando il file NCache installazione, puoi semplicemente aggiungerlo come pacchetto NuGet. Devi solo installarlo all'interno del progetto del prodotto delle tue applicazioni.
Il prossimo passo qui è includere questi due spazi dei nomi Alachisoft.NCache.Segnale R e poi Microsoft Microsoft.AspNet.SignalR. Quindi, questi devono essere introdotti in Startup.cs, seguirò solo il progetto di esempio ma devi farlo in riferimento alla tua configurazione specifica. Quindi, se vai in Startup.cs proprio qui, vai proprio in alto, possiamo vedere che questi due sono già riferimenti qui Alachisoft.NCache.Segnale R ed Microsoft.AspNet.SignalR. Quindi, è già sommato qui.
Diamo un'occhiata al passaggio successivo. Quindi, ora dobbiamo modificare web.config. Quindi, dobbiamo aggiungere queste due chiavi specifiche proprio qui e lascia che ti spieghi cosa sono? Il primo, che è il nome della cache, è il nome effettivo della cache. Quindi, devi dargli la cache che la utilizzerai, che sarà attiva e funzionante e devi usarla.
La seconda è la chiave pari e questo è ciò che differenzia tra multiplo. Quindi, se hai la stessa cache utilizzata come supporto come backplane per più applicazioni diverse. Giusto, quindi, questo è ciò che lo differenzia. Quindi, sostanzialmente si apre un canale all'interno della cache attraverso il quale tutte le applicazioni, che hanno lo stesso valore, potrebbero essere notificate. Quindi, se ci sono due applicazioni che devono comunicare tra loro, devono avere questo valore per essere lo stesso, ma se ci sono applicazioni diverse, puoi cambiarlo in base al tuo ambiente specifico. Quindi, in questo momento, si dice Chat proprio qui e se torniamo al progetto di esempio proprio qui e andiamo in web.config, possiamo vedere che è impostato proprio qui.
Il nome della cache è diverso e quello che farò è cambiarlo nella cache che abbiamo creato e che è signalrcache. Come accennato in precedenza, questo è il nome della cache non fa distinzione tra maiuscole e minuscole, quindi puoi andare solo con questo. Quindi, vado avanti e salverò questo. Torniamo qui, quindi queste cose sono fondamentalmente, questi sono i sovraccarichi che possono essere utilizzati, mostrerò cosa sto usando nel mio ambiente. Inizialmente ti stai solo registrando su variabili di tipo stringa, che assumeranno i valori che abbiamo inizialmente memorizzato all'interno di web.config. Questo è il nome della cache così come il canale, ad esempio, il nome e quindi è qui che lo specifichi NCache dovrebbe essere utilizzabile. Fondamentalmente, sono solo due o tre righe di codice che devono essere introdotte all'interno dell'applicazione. Dovresti essere a posto per usarlo NCache come backplane all'interno dell'applicazione.
Inizialmente c'era una domanda che si riferiva a quanto fosse difficile configure NCache come backplane per la tua applicazione specifica ed è abbastanza facile. Quindi, ci sono solo tre righe di codice che devono essere introdotte e dovresti averlo NCache essere come backplane per il tuo ambiente specifico e se torno al mio progetto proprio qui, andando su startup.cs. Abbiamo lo stesso codice specifico. Ci sono solo alcuni controlli presenti qui, solo per garantire che i valori che sono effettivamente a posto e quindi proprio qui. Abbiamo questa chiamata proprio qui, che introduce NCache da utilizzare come backplane per questo. Quindi, quello che farò ora è che eseguirò questa applicazione e aprirò un paio di istanze di essa. Quindi, posso mostrarti come funziona questa chat room in questo momento. Quindi, farò semplicemente clic su Esegui proprio qui e dovrebbe aprirlo. Bene. Quindi, la build è completata, dovrebbe aprirsi ora. Va bene, sto solo aspettando il carico, non ci vuole così tanto ma è proprio ora.
Va bene, nel frattempo, lasciami scorrere rapidamente le diapositive che stiamo utilizzando. Quindi, se faccio clic su Default.html proprio qui, dovrebbe apparire un pop-up qui, che mi chiede il nome che userò. Quindi, poiché questa è una chatroom, devi registrarti come con il nome. Quindi, quando invii un messaggio, gli altri destinatari dovrebbero sapere esattamente da chi proviene questo messaggio. Quindi, proprio qui, mi sta chiedendo il mio nome. Vado solo avanti e darò il nome Kal. Scriverò ciao e proverò a inviarlo, nel frattempo aprirò un'altra istanza proprio qui, dovrebbe aprirsi. Ancora non l'ha inviato ma verifichiamo che il nome della cache fosse corretto, torniamo a web.config. Penso di aver sbagliato il nome. Quindi, è signalrache. Potrebbe essere necessario eseguirlo di nuovo. Vado solo avanti e mi fermo, ovviamente chiuderò queste istanze poiché il nome della cache non era corretto. Questi non funzionerebbero, quindi ho bisogno di eseguirli di nuovo. Bene. Quindi, verifichiamo ancora una volta signalrcache, ora è corretto. Sta arrestando le istanze a questo punto. Va bene, lo eseguirò ancora una volta, questo dovrebbe essere più veloce perché già fatto.
Nel frattempo, se hai domande? Prego, sentiti libero di chiedere. Bene. Quindi, la build è terminata e ora lo stiamo solo aprendo bene. Quindi, Kal ho una domanda qui, funziona anche per il core di SignalR? Sì, funziona perché NCache supporta per .NET Core anche. Quindi, funziona con quel sì. Va bene un'altra domanda è quali capacità di messaggistica NCache offerte diverse da SignalR? Come ho inizialmente menzionato sotto SignalR l'intera implementazione come backplane, NCache utilizza il modello Pub/Sub, ma a parte questo è possibile utilizzare anche Pub/Sub separatamente. Deve sempre essere utilizzato come backplane per SignalR, ma in caso contrario, abbiamo eventi e gli eventi possono essere eventi guidati dai dati o possono essere anche eventi specifici definiti dall'utente con i quali puoi sostanzialmente notificare ad altre applicazioni determinati eventi. L'elemento più recente viene aggiunto, aggiornato o eliminato e abbiamo queste funzionalità, quindi hai anche la funzione di query continua.
Quindi, con quello in specifica determinati risultati impostati all'interno della cache e se qualsiasi aggiornamento viene eseguito su quello specifico, set di risultati e potrebbero essere più elementi all'interno della stessa cache e qualcuno di essi viene aggiornato, sarà il client che ha richiesto perché ottiene verrà informato al riguardo, quindi questi sono anche altri che sono presenti. Quindi, ho appena cliccato su quello predefinito. Dovrebbe chiedermi il mio nome, ora lo aspetterò. Bene. Quindi, gli darò il nome, Kal e, si spera, funzionerà. Quindi, scriverò semplicemente ciao e lo invierò. In questo momento, copierò questo link e incollerò proprio qui. Ok, fornendo il nome gli darò solo il nome Nick. Va bene qui, quindi qui da qui, ho inviato un messaggio dicendo ciao ed è stato ricevuto anche qui. Allora, questo è il saluto di Nick. Quindi, scriverò il saluto di Nick e lo manderò. Quindi, proprio qui, Nick invia questo messaggio di saluto da Nick e se guardi indietro nel punto di vista di Kal, possiamo vederlo anche qui.
Quindi, possiamo inviare più messaggi qui, quanto vogliamo e verranno ricevuti a tutti i client collegati a questo scenario specifico. Quindi, possiamo vedere che Kal ha inviato un sacco di messaggi e sono stati ricevuti anche dal punto di vista di Nick. Quindi, vengono aggiornati automaticamente, se ne invii un ultimo anche da Nick e dal Nick e lo mandi semplicemente, puoi vederlo uscito da Nick e anche da questa vista, possiamo vedere bene qui. Quindi, se osserviamo rapidamente la cache che abbiamo creato e che viene utilizzata da lui. Possiamo vedere che è stato aggiunto un elemento qui e, come accennato in precedenza, viene aggiunto solo un oggetto, il resto è solo una coda che viene temporaneamente mantenuta mentre viene trasferita.
Quindi, se usiamo uno strumento all'interno NCache che si chiama dump cache keys, scaricherà le chiavi che sono presenti all'interno della cache. Quindi, voglio solo mostrartelo rapidamente e gli diamo il nome signalrcache e premiamo invio.
Riprenderà tutti gli elementi presenti nella cache. Quindi, a questo punto sono solo uno e possiamo vedere che c'è questo elemento posizionato qui, con il nome chat e questo valore di stringa è esattamente lo stesso che abbiamo configurato all'interno della nostra applicazione rispetto al valore della chiave dell'evento. Quindi, questa è la chiave comune che deve essere utilizzata all'interno di tutte le tue applicazioni, che devono utilizzare questo canale specifico per inviare e ricevere messaggi. Quindi, questo deve essere lo stesso ovunque e questo è esattamente ciò che assicurerà che tutti i client collegati o i server Web collegati a questa cache specifica vengano avvisati e riguardo a qualsiasi cosa stia accadendo. Quindi, ecco com'è facile averlo NCache come backplane all'interno dell'applicazione.
Se sfoglio rapidamente ciò di cui abbiamo già discusso qui, lasciami finire rapidamente l'ultima schermata e l'ultima diapositiva della presentazione ecco quella NCache sotto di esso. Usando il modello Pub/Sub.
Quindi, hai applicazioni client collegate, che possono essere applicazioni .NET o applicazioni java e sono connesse come per editori e abbonati in entrambe le direzioni. Quindi, qualsiasi applicazione che invia un client connesso inviando un messaggio indovina, riceve a tutti i client connessi e in questo modo garantisce che tutti i messaggi vengano effettivamente ricevuti da tutti i client connessi.
Quindi, se sfogli rapidamente ciò di cui abbiamo discusso in questo webinar di oggi, è che abbiamo discusso di SignalR come tecnologia. Che cos'è e come può aiutare in diversi scenari? Dove è un disperato bisogno perché le applicazioni non possono aspettare che il client invii effettivamente una notifica o solo allora possono rispondere con i rispettivi dati. Vogliono che i clienti vengano avvisati automaticamente del tuo aggiornamento con i dati aggiornati abbastanza rapidamente. Quindi, abbiamo discusso di cos'è SignalR? Come funziona fondamentalmente? Quali sono i diversi casi d'uso che sono possibili possibilità e dove viene attualmente utilizzato anche SignalR?
Quindi, non sono solo casi d'uso futuri. Sono anche casi d'uso attuali e come la scalabilità orizzontale delle app SignalR può avere una sorta di problemi con la coerenza e come gli stessi SignalR hanno introdotto il concetto di backplane attraverso il quale possono garantire che tutti i client connessi abbiano una vista coerente e ottengano notificato immediatamente di qualsiasi cosa, che sta succedendo all'interno della cache. Penso che ci sia una domanda.
Bene. Quindi, lasciatemi discutere i colli di bottiglia associati al SignalR Backplane. Abbiamo discusso questi tre punti principali e questi, come ho detto prima, erano anche le opportunità che qualsiasi soluzione poteva cogliere e la soluzione di cui abbiamo parlato era una cache distribuita in memoria. In questo caso lo era NCache e abbiamo mappato le diverse caratteristiche, cose diverse che NCache possiede oltre, cosa a SignalR Backplane ha davvero bisogno? NCache mappato perfettamente su di loro ed è stato un caso d'uso eccellente, fondamentalmente un candidato eccellente, essere un backplane per un'applicazione SignalR e abbiamo discusso di NCache. Come NCache può essere utilizzata? Abbiamo discusso i numeri di scalabilità e siamo anche passati alla demo pratica del progetto di esempio, che viene installato NCache e come può essere utilizzato e poi c'è questa documentazione proprio qui, che aiuta attraverso ogni singolo processo di questa configurazione.
Quindi, penso che questo sia tutto dalla mia parte, Nick a te. Grazie, Kal, è stato molto istruttivo, se qualcuno ha domande gentilmente faccelo sapere o puoi digitare quelle domande nella casella delle domande. Giusto per ricapitolare il NCache è disponibile una soluzione scaricare dal nostro sito www.alachisoft.com. Abbiamo l'edizione community, la versione open source e il Edizione Enterprise che puoi scaricare, dai un'occhiata a enterprise viene fornito con un periodo di prova di 30 giorni, che puoi utilizzare per testare prima di procedere e l'open source è ovviamente gratuito. Quindi, non ci sono domande, vorrei ringraziare tutti per essersi uniti a noi e ringrazia Kal per il tuo tempo e non vedo l'ora di vederti al prossimo futuro webinar.