Cinque potenziatori di prestazioni ASP.NET
Webinar registrato
Di Ron Hussain e Nick Zulfiqar
Scopri come aumentare le prestazioni e la scalabilità di ASP.NET con una cache .NET distribuita. Guarda questo webinar per scoprire i cinque modi per aumentare le prestazioni di ASP.NET per la scalabilità nelle applicazioni ASP.NET e come utilizzare una cache distribuita in memoria per risolverli in modo efficace.
In collaborazione con il nostro Senior Solutions Architect e Regional Sales Director, unisciti a noi per conoscere:
- Cache dei dati dell'applicazione ASP.NET
- Memorizzazione nella cache dello stato della sessione ASP.NET
- ASP.NET SignalR Backplane utilizzando la cache distribuita
- ASP.NET View State Caching
- Cache di output ASP.NET
Oggi parleremo di 5 modi per aumentare le prestazioni e la scalabilità dell'applicazione ASP.NET. È un argomento molto caldo, direi che è qualcosa che è molto richiesto. Quindi, siamo lieti di portare questo per te. Ron ne parlerà tra un minuto e inoltre, se hai domande durante questa presentazione, sentiti libero di inserirle nel video e sarò in grado di portarle all'attenzione di Ron.
Allora, Ron, come inizi? Grazie, Nick. Ciao a tutti, mi chiamo Ron e sarò il vostro presentatore per il webinar di oggi e, come ha suggerito Nick, l'argomento che abbiamo scelto oggi è di cinque potenziamenti delle prestazioni di ASP.NET. Quindi, esamineremo cinque diverse funzionalità. Inizialmente, parlerò di cinque diversi problemi, quelli che vedresti in genere all'interno di un'applicazione Web ASP.NET, questi sono problemi quotidiani che in realtà rallentano le tue applicazioni, il suo degrado delle prestazioni, quindi la scalabilità è un'altra strada, un altro aspetto in cui parleremo di questi colli di bottiglia e poi parlerò di diverse soluzioni con l'aiuto del sistema di caching distribuito. Come risolvere questi problemi all'interno delle applicazioni ASP.NET? Quindi, questo è ciò che abbiamo preparato oggi, tratterò diverse funzionalità, avrò applicazioni di esempio, ti mostrerò tutto in azione come configurare e iniziare con questo. Quindi, sarà un webinar piuttosto interattivo e pratico e, come ha detto Nick, se ci sono domande non esitare a partecipare e sarò molto felice di rispondere a tutte queste domande per te. Va bene, supponendo che tutto sia a posto, inizierò con questo.
ASP.NET è popolare per le app Web ad alto traffico
Quindi, prima di tutto, parlerò della piattaforma ASP.NET in generale. ASP.NET è una piattaforma molto popolare per le applicazioni web. Vediamo molte implementazioni web e la sua popolarità sta aumentando. La cosa bella della piattaforma ASP.NET è che, si basa sul modello di utilizzo, è qualcosa che si ridimensiona abbastanza bene, puoi gestire migliaia di utenti simultanei e le loro richieste associate senza dover modificare nulla all'interno dell'architettura dell'applicazione. Puoi creare una web farm, puoi creare un web garden, ti offre molte opzioni di scalabilità, puoi mettere un load balancer davanti e quindi puoi instradare le richieste tra diversi server web e puoi ottenere scalabilità lineare, scalabilità orizzontale dalla web farm ASP.NET.
Un servizio di bilanciamento del carico potrebbe avere un bilanciamento del carico permanente o un bilanciamento del carico uguale a seconda della tua architettura, a seconda della natura con stato dei tuoi server Web o server delle app, quindi puoi scalare in base alle tue esigenze.
Quindi, questa è una tipica distribuzione di una web farm per le applicazioni ASP.NET, hai N numero di client che passano attraverso il servizio di bilanciamento del carico per configurare server web all'interno di una web farm e quindi hai l'archiviazione di sessione ASP.NET, questo è un tipo di dati che potresti vedere all'interno delle tue applicazioni web ASP.NET. Quindi saranno server di database, database relazionali o NoSQL databases potresti avere a che fare con molti dati avanti e indietro e quindi potrebbe essere qualsiasi altro file system mainframe del sistema di dati back-end con cui interagiscono le tue applicazioni. Quindi, questo è piuttosto popolare, abbastanza scalabile, abbastanza veloce e molte implementazioni attive utilizzano questa piattaforma.
Il problema: colli di bottiglia della scalabilità
Quindi, parliamo del collo di bottiglia della scalabilità all'interno di ASP.NET. Dov'è esattamente il problema? È qualcosa che ridimensiona molto bene il problema della scalabilità e definiamo rapidamente cos'è la scalabilità? La scalabilità è un'abilità all'interno dell'architettura dell'applicazione o all'interno dell'ambiente in cui viene distribuita l'applicazione. È quell'abilità in cui puoi aumentare il numero di richieste al secondo o richieste, richieste simultanee senza compromettere le prestazioni. Se hai una certa quantità di latenza, diciamo cinque utenti. Che ne dici di mantenere quella latenza? Non degraderai le prestazioni e va bene non migliorare le prestazioni, ma almeno mantieni le prestazioni al di sotto di 5000 utenti o 500,000 utenti quella capacità stessa è chiamata scalabilità, in cui ottieni il massimo throughput dal sistema, vengono caricati sempre più richieste gestito e quindi la latenza non aumenta con l'aumento dei carichi degli utenti. Quindi, sono essenzialmente prestazioni sotto carico estremo o prestazioni estreme sotto carico estremo. Quindi, quella capacità è chiamata scalabilità.
Ora, in genere le applicazioni ASP.NET, sebbene la Web farm sia molto scalabile, ora darebbero problemi di scalabilità all'interno della Web farm, ma possono causare lentezza nei picchi di carico principalmente a causa delle origini dati di back-end. Quindi, se la tua applicazione rallenta, si blocca a causa di un'enorme quantità di carico, quindi quell'applicazione è un candidato per la scalabilità, deve avere un'architettura scalabile al suo interno. Perché l'applicazione sentirebbe il tuo mondo o vedresti situazioni come questa in cui le applicazioni rallentano sotto carico di picco, potrebbero esserci colli di bottiglia classificati per l'archiviazione dei dati diversi o alcuni colli di bottiglia all'interno dell'applicazione. Quindi, da questo punto in poi parleremo di cinque diversi colli di bottiglia all'interno di un'applicazione ASP.NET che limita la tua capacità di scalabilità, che limita la scalabilità orizzontale.
Due colli di bottiglia nell'archiviazione dei dati
Bene. Quindi, prima di tutto, abbiamo due colli di bottiglia nell'archiviazione dei dati.
Il database non può scalare
Abbiamo un database dell'applicazione che in genere non può essere ridimensionato, avresti un database relazionale sotto forma di SQL Server, Oracle o qualsiasi altra fonte di dati relazionale popolare. È molto buono per l'archiviazione ma non è molto buono quando si tratta di gestire un'enorme quantità di carico di transazioni. Tende a soffocare e, in alcuni casi, ti dà effettivamente errori di timeout. Quindi, o almeno rallenta effettivamente le tue prestazioni, non puoi aggiungere più server di database al volo, quindi sarà un'unica fonte. In alcuni casi è anche un singolo punto di errore se non si dispone della replica e quindi il problema più importante qui è che non è molto veloce, è lento in uno scenario normale e quindi sotto carico di picco e in realtà peggiora la situazione in cui non è in grado di sopportare l'aumento del carico e rallenta ulteriormente le cose. Quindi, questo è il nostro primo collo di bottiglia.
Archiviazione dello stato della sessione ASP.NET
Il secondo collo di bottiglia riguarda l'archiviazione dello stato della sessione ASP.NET, ora lo stato della sessione è un tipo di dati molto importante. È qualcosa che contiene informazioni sull'utente, ad esempio, potrebbe esserci un'applicazione di e-commerce in cui si mantengono le informazioni sull'utente o il carrello degli acquisti, potrebbe essere un sistema di prenotazione, potrebbe essere un sistema di biglietteria, potrebbe essere il tuo sistema finanziario. Quindi, potrebbe essere qualsiasi tipo di sistema frontale in cui gli utenti accedono e hanno i loro dati molto importanti all'interno di questo oggetto sessione.
Ora, queste sono le tre modalità offerte dalla piattaforma ASP.NET, abbiamo InProc in cui tutto viene archiviato all'interno del processo di lavoro. Quindi, tutto si trova all'interno del processo dell'applicazione, quindi i tuoi processi di lavoro non sono stateless, il protocollo HTTP stesso è senza stato, ma in questo caso i tuoi processi di lavoro ospiterebbero tutti i dati dell'utente stessi. Quindi abbiamo StateServer quella seconda opzione e poi abbiamo SQL Server. Quindi, parliamo di queste opzioni di archiviazione dello stato della sessione convenzionali e parliamo dei loro colli di bottiglia.
Innanzitutto, InProc è veloce perché è in memoria, non c'è la deserializzazione della serializzazione ma come rovescio della medaglia, prima di tutto, non puoi gestire uno scenario di web garden. Su un server Web avresti un solo processo di lavoro per una determinata applicazione perché è lì che esistono i dati della tua sessione ora se la richiesta successiva va a un altro processo di lavoro, non hai più quei dati di sessione deve essere lo stesso processo di lavoro e questo è il motivo per cui ti limita, tecnicamente non è possibile eseguire Web Garden con la gestione delle sessioni InProc, quindi questo è un fattore limitante qui.
In secondo luogo, è necessario abilitare il bit di sessione permanente sul bilanciamento del carico. Quindi, prima di tutto, hai limitato le tue prestazioni o scalabilità o le tue risorse sul server web e disponendo di un solo processo per un'applicazione. In secondo luogo, i tuoi server web in cui è stata servita la richiesta iniziale, le richieste successive andrebbero sempre allo stesso server. Questo è tutto il bilanciamento del carico della sessione appiccicosa funziona, fa il lavoro ma il problema principale con questo è che potrebbe essere che un server Web ha molti utenti attivi ma altri server Web sono inattivi perché quegli utenti sono già stati disconnessi e dal momento che gli utenti saranno di natura appiccicosa, non andrebbero mai su questo server gratuito, andrebbero sempre sullo stesso server in cui devono andare con i dati esistenti. Quindi, questo è un altro problema che devi avere un bilanciamento del carico della sessione persistente con InProc e, soprattutto, se il tuo processo di lavoro viene riciclato e abbiamo visto, in base alla nostra esperienza, i processi di lavoro ASP.NET vengono riciclati abbastanza, perderesti tutto i dati giusti, se si tratta di un'attività correlata alla manutenzione, se il server ha bisogno di andare inattivo devi portare un server web giù portare un altro server web su perdi tutti i dati di conseguenza. Quindi, questo riassume tutti i problemi, tutti i colli di bottiglia che vedresti con la gestione delle sessioni InProc con un ASP.NET. Quindi, chiaramente non è un'opzione e inoltre non è molto scalabile, hai un server di cui hai raggiunto la capacità di quel server e con sticky è un bilanciamento del carico non aiuta davvero.
La seconda opzione è StateServer, è leggermente migliore di InProc perché rimuove i dati dal processo di applicazione all'interno di un servizio di stato, potrebbe essere una scatola remota o uno dei tuoi server Web, dipende interamente da te ma il problema è che non lo è scalabile, è un'unica fonte, puoi aumentare la scalabilità su quel server ma la scalabilità orizzontale non è un'opzione. Sarà sempre un server singolo, un servizio che ospiterà tutti i dati della tua sessione e che gestirà anche il carico di tutte le richieste, se il carico delle tue richieste aumenta, non ci sono opzioni per aggiungere più risorse. Quindi, non aumenterà la scalabilità in confronto alla fine il tuo servizio statale può soffocare, ad esempio, se hai centinaia e migliaia di utenti e la loro richiesta associata rende milioni di richieste al secondo o al giorno richiedente o all'interno di milioni è un carico piuttosto pesante . Quindi, sulla base di quello StateServer non sarebbe scalabile e non sarebbe in grado di far fronte all'aumento del carico, e quindi è anche un singolo punto di errore. Se StateServer stesso si interrompe, perdi tutti i dati della sessione e i dati della sessione sono un tipo molto importante di dati che non vorresti perdere le sessioni mentre il tuo utente sta per acquistare qualcosa o sta per prendere una decisione e avrà un impatto il business in cambio.
La terza opzione è SQL Server. SQL Server è ancora una volta una gestione della sessione fuori processo, ma ancora una volta è lenta, non è scalabile, non è possibile aggiungere più SQL Server e non è pensato per gestire i dati transazionali da soli, quindi si finisce per avere lo stesso problema di cui abbiamo discusso come parte del nostro database dell'applicazione, il problema rimane lo stesso per la memorizzazione nella cache dei dati e per la memorizzazione nella cache della sessione. Quindi, lo stato della sessione non è qualcosa che verrà ottimizzato con le opzioni predefinite presentate dalla piattaforma ASP.NET e ciò è principalmente dovuto alle origini dati che offre InProc, StateServer e SQL Server.
Spero che questo abbia costruito alcuni dettagli di base attorno ai colli di bottiglia e ovviamente parleremo della soluzione, stiamo parlando della cache distribuita e delle sue funzionalità a confronto e parleremo di come occuparci di questi problemi uno per uno , quindi voglio prima elencare tutti i problemi e poi parleremo delle soluzioni una per una. Questo diagramma illustra lo stesso.
Abbiamo il database del collo di bottiglia dell'archiviazione dei dati e poi abbiamo l'archiviazione della sessione ASP.NET o InProc o database come gestore di sessione e anche questo chiaramente costituisce un collo di bottiglia, in cui nella maggior parte dei casi abbiamo origini singole, non sono scalabili, non lo sono molto affidabile e poi c'è lento in generale.
ASP.NET View State Strozzatura
Ora c'è il terzo collo di bottiglia importante ASP.NET view state. Per le web farm ASP.NET esiste uno stato di visualizzazione, ora chi di voi vuole sapere qual è lo stato di visualizzazione? Sono abbastanza sicuro che tutti lo sappiano, ma lo stato di visualizzazione è una gestione dello stato lato client, è un pacchetto, è uno stato dei tuoi widget di controllo che hai nelle tue web farm, viene costruito sul lato server e diventa parte del tuo il pacchetto di risposta torna al browser in cui è archiviato, non viene mai realmente utilizzato sul browser e viene riportato al server quando pubblichi di nuovo su quella pagina come parte del pacchetto di richiesta disperso. Quindi, viene fornito in bundle con i pacchetti di richiesta e risposta, torna al browser, non viene mai realmente utilizzato lì e un problema urgente con lo stato di visualizzazione è che generalmente è molto pesante. Ha una dimensione di centinaia di kilobyte e pensa allo scenario, in cui hai un'enorme quantità di carico di transazione, abbiamo milioni di transazioni e quindi ogni transazione ha un pacchetto di pacchetti dello stato di visualizzazione o un pacchetto di risposta alla richiesta per l'applicazione Web ASP.NET ha visualizza stato parte di esso e se hai centinaia di kilobyte di stato di visualizzazione per richiesta e hai milioni di transazioni, consumerà molta larghezza di banda e in generale rallenterebbe le risposte della tua pagina perché hai a che fare con molti dati avanti e indietro e anche quei dati sono di dimensioni pesanti.
Quindi, questo è un altro collo di bottiglia che consuma la tua larghezza di banda, la tua causa aumenta in modo significativo e quindi rallenta i tempi di risposta della tua pagina perché lo stato di visualizzazione è generalmente pesante, hai a che fare con un carico utile più pesante per le richieste in risposta. Quindi, questo è un altro tipo di collo di bottiglia che fa parte delle web farm ASP.NET. Se si dispone di un'applicazione Web farm ASP.NET, non c'è modo di sfuggire a questo problema. Per impostazione predefinita, dovresti avere a che fare con molto stato di visualizzazione e questo diagramma lo copre dove lo stato di visualizzazione torna al browser, è una gestione dello stato lato client viene costruita sul lato server e torna al browser e lo porta di nuovo sul server sul tuo post back. Ora i pacchetti di richiesta e risposta sono pesanti, consumano molta larghezza di banda e anche un carico utile pesante rallenta le cose.
Collo di bottiglia aggiuntivo nell'esecuzione della pagina
Ora il quarto collo di bottiglia e questo è il penultimo, abbiamo un altro collo di bottiglia dopo che questo è il collo di bottiglia dell'esecuzione della pagina in più. Ora questo è vero per le web farm ASP.NET così come per le applicazioni web ASP.NET MVC. Ci sono scenari in cui l'output dell'intera pagina è lo stesso o le parti all'interno di una pagina dinamica sono le stesse, quindi hai a che fare con contenuto statico all'interno dell'applicazione molto frequentemente. Quindi, l'output della pagina non cambia molto frequentemente ma stai ancora eseguendo quelle richieste. Potrebbe esserci una richiesta e coinvolge alcuni database di back-end che vengono visualizzati e quindi si recuperano alcuni dati dalle origini dati di back-end, si leggono quei dati, si rendono significativi l'applicazione di un livello di logica aziendale quotidiana, il livello di accesso ai dati tutto il roba buona e dopo di che si esegue una risposta e la risposta viene rispedita all'utente finale nel browser. Ora, qualunque cosa lo stesso ciclo debba ripetere e poi il contenuto non sta cambiando, dovresti ripetere lo stesso ciclo ancora e ancora e ancora. Questa pagina viene eseguita indipendentemente dal fatto che cambi o meno, per impostazione predefinita hai a che fare con molto contenuto statico e sebbene il contenuto non stia cambiando ma stai ancora eseguendo la stessa richiesta. Ora questo aumenta i costi dell'infrastruttura, CPU extra, memoria extra, risorse di database extra, può raggiungere la capacità sul server Web, può anche raggiungere la capacità sul sito del database in generale è qualcosa che sprecherebbe molta CPU e risorse costose nell'esecuzione di qualcosa che è già stato eseguito. Quindi, questo è un altro collo di bottiglia e parleremo di una soluzione con l'aiuto della memorizzazione nella cache dell'output della pagina come occuparci anche di questo. Quindi, questo copre il nostro quarto collo di bottiglia e il quinto e, tra l'altro, questo diagramma prevede l'esecuzione di pagine su output statico e ha creato più database con molte richieste.
ASP.NET SignalR Backplane Strozzatura
E il quinto collo di bottiglia lo è SignalR backplane. Ora questo è un caso d'uso molto specifico in cui potresti avere o meno SignalR, ma per quelli di voi che hanno familiarità con SignalR e se avete impostato un backplane, proprio un backplane è un bus di messaggi comune e il vostro server web invia tutti i loro messaggi invece di inviare la funzionalità push sui browser client. Potrebbe esserci uno scenario in cui poche richieste client vengono gestite con altri server Web. Quindi, siamo semplicemente trasmessi al backplane e al backplane a sua volta trasmettono messaggi, SignalR messaggi a tutti i server Web e questi a loro volta trasmettono a tutti i client connessi. Quindi, con WebSocket ASP.NET SignalR backplane è una configurazione abbastanza comune, se si dispone di una web farm.
Adesso SignalR Backplane NCache o qualsiasi altro prodotto di cache distribuita può essere collegato. Può anche essere un database o potrebbe anche essere un bus di messaggi, ma l'idea qui è che il backplane non dovrebbe avere problemi di prestazioni o velocità effettiva. Dovrebbe funzionare molto bene, dovrebbe darti una bassa latenza, darti un throughput elevato e, allo stesso tempo, dovrebbe essere molto affidabile se va giù e perdi tutti i messaggi di SignalR che avrebbero un impatto anche sull'attività.
I database sono lenti, non sono molto scalabili, hanno prestazioni lente, Redis è un'opzione non è .NET nativo, quindi hai bisogno di qualcosa che sia molto scalabile, che sia molto veloce ed è anche molto affidabile. Quindi, questo è un altro problema all'interno di un'applicazione ASP.NET se la stai utilizzando SignalR backplane di conseguenza. Quindi, questo completa i nostri cinque colli di bottiglia, so che sono molte informazioni ma principalmente il suo database è lento, non essendo molto scalabile, lo stato della sessione ASP.NET non ha opzioni molto scalabili o veloci o affidabili per impostazione predefinita. View State for ASP.NET Web farm è anche un collo di bottiglia, la sua fonte di contesa, l'utilizzo eccessivo della larghezza di banda, le pagine statiche all'interno dell'applicazione verranno eseguite indipendentemente dal fatto che il contenuto dell'applicazione stia cambiando o meno. Verrà eseguito e poi lo abbiamo fatto SignalR Backplane che è generalmente lento e non è molto affidabile, non è molto scalabile e hai bisogno di qualcosa che sia molto scalabile molto affidabile in confronto.
Quindi, questo completa i nostri cinque colli di bottiglia, nelle prossime diapositive parlerò della soluzione e quindi esamineremo tutti questi colli di bottiglia uno per uno e presenterò soluzioni diverse. Per favore fatemi sapere se ci sono domande e sarò molto felice di rispondere a queste domande per voi in questo momento. Ho alcuni esempi di applicazioni di esempio allineati qui, quindi li userò bene. Quindi, penso che a questo punto non ci siano domande. Quindi, inizierò rapidamente con la soluzione perché abbiamo molto da coprire nel nostro prossimo segmento.
La soluzione: cache distribuita in memoria
Abbiamo la cache distribuita in memoria come soluzione e la userò NCache come prodotto di esempio. NCache è il principale prodotto di cache distribuita, cache distribuita basata su .NET, è scritto per .NET ed è principalmente per applicazioni .NET ed è uno dei nostri prodotti principali. userò NCache come prodotto di esempio e parleremo di cinque diverse funzionalità all'interno NCache questo si occuperà di questo e vedresti un aumento delle prestazioni all'interno della tua applicazione ASP.NET. Migliorerebbe notevolmente le prestazioni e la scalabilità e queste sono solo funzionalità specifiche di ASP.NET, ci sono altre funzionalità lato server che puoi ottimizzare, c'è un webinar separato su come migliorare NCache performance, che porterà le cose a un livello completamente nuovo, che migliorerà ulteriormente le prestazioni, ma in questo webinar parlerò di cinque diversi colli di bottiglia e poi di cinque diverse soluzioni a quei colli di bottiglia.
Che cos'è una cache distribuita in memoria?
Quindi, cos'è una cache distribuita in memoria e in che modo è più veloce, più scalabile e in alcuni casi più affidabile in confronto? Quindi, la cache distribuita è un cluster di più server cache economici che sono raggruppati in una capacità logica per la loro memoria, CPU e risorse di rete. Quindi, se hai un team di server e quei team di server sono uniti in un cluster, è una capacità logica per le applicazioni ma è un insieme fisico di server o VM, quindi dietro di noi ci sono più risorse e hai la capacità di aggiungi più server al volo. Quindi, server di cache economici, si uniscono, si uniscono e mettono in comune le loro risorse e questo è ciò che costituisce la base di una cache distribuita.
Quindi abbiamo sincronizzato gli aggiornamenti della cache tra i server della cache, è molto coerente in termini di dati rispetto a perché ci sono più server, più applicazioni client si collegano ad esso, quindi qualsiasi aggiornamento effettuato su un server cache deve essere visibile su altri server cache web e anche ai clienti che sono collegati ad esso e ho usato il termine visibile, il che significa che deve essere coerente. Non ho usato la replica come termine qui, la replica è un altro concetto. Pertanto, tutti gli aggiornamenti vengono applicati in modo sincronizzato o in modo coerente su tutti i server di memorizzazione nella cache, in modo da avere la stessa visualizzazione dei dati per tutte le applicazioni client.
Quindi dovrebbe essere ridimensionato sia per le transazioni che per la capacità di memoria e anche per altre risorse. Se aggiungi più server, dovrebbe semplicemente aumentare la capacità, se hai due server e porti il terzo server, in precedenza gestivi diciamo 10,000 richieste con un terzo server, dovrebbe portarlo a 15,000 con altri due server che raddoppiano la capacità, dovrebbe gestire 20,000 richieste al secondo e questa è la nostra esperienza. In realtà aumenta la capacità e la capacità complessiva di gestione delle richieste aumenta man mano che aggiungi il numero di server e ti mostrerò alcuni numeri di riferimento per supportarlo. Questa è l'architettura di distribuzione della tipica cache distribuita.
Hai un team di server cache, tutti gli ambienti Windows sono supportati dal 2008 al 2012 e tutte le tue applicazioni si connettono ad esso in un modello client-server e usano questa fonte veloce, scalabile e affidabile oltre al nostro database relazionale. Un giorno daranno che esiste nel database relazionale, puoi portare alcuni o tutti i tuoi dati nella cache. Stato della sessione questo diventa il tuo negozio principale, lo stato di visualizzazione, la cache di output, SignalR backplane questo diventa il tuo principale fornitore per quello.
NCache Benchmark delle prestazioni
Lascia che ti mostri alcuni numeri di riferimento per supportare il fatto che è molto scalabile. Sul nostro sito questi numeri sono pubblicati. Quindi, questi sono i dettagli del test e quindi se guardi alle prestazioni, questo sta crescendo per le letture non così lineare per le scritture, ma questa è la topologia che useremo nel webinar di oggi, le letture e le scritture stanno crescendo linearmente e questo ha letture e scritture in crescita lineare così come i backup. Quindi, questo viene fornito anche con il supporto del backup, ecco perché le prestazioni o la capacità di scrittura sono leggermente inferiori rispetto alla partizione che non ha alcun backup, quindi anche questo ha un sovraccarico del backup. Quindi, questa è la nostra topologia più popolare per letture e scritture e man mano che si aggiungono più server, aumenta anche la capacità.
Mani sulla demo
Permettetemi di portarvi nel nostro ambiente demo, impostare una cache distribuita e quindi iniziare con queste funzionalità una per una e ragazzi, per favore, voglio dire se ci sono domande?
Userò, ho già scaricato installato NCache, lo scopo di questo webinar non è disponibile NCache configurazioni o impostazioni. Quindi, salterò alcuni dettagli qui, ma solo per farti sapere, l'ho fatto scaricata NCache dal nostro sito Web una versione di prova completamente funzionante e quindi l'ho installata su due delle mie caselle di server cache e una macchina alla mia estremità verrà utilizzata come client. Puoi installare NCache anche sul client oppure puoi usare i pacchetti NuGet secondo necessità.
Crea una cache
Creerò solo una cache, chiamiamola aspnetcache perché è quello che ci focalizziamo oggi.
Sceglierò la cache della replica della partizione e tutte queste impostazioni saranno discusse in dettaglio nel nostro normale NCache architettura webinar.
Opzione di replica asincrona e qui, specifico i server che inizialmente faranno parte del mio cluster di cache.
Mantieni tutto uguale per la porta TCP/IP. NCache è una comunicazione basata su TCP/IP, la comunicazione server-server e client-server è gestita tramite TCP/IP e quindi la dimensione della cache su ciascun server, manterrò tutto predefinito, manterrò gli sfratti predefiniti e sceglierò fine e il gioco è fatto.
È così facile impostare la cache. Nel riquadro di destra abbiamo tutte le impostazioni relative a questa cache e tra l'altro puoi anche impostare le righe di comando e gli strumenti di PowerShell e quindi puoi gestire tutto anche dalla riga di comando o da PowerShell. Aggiungerò mybox da dove prevedo di eseguire le applicazioni. Quindi, che abbiamo le configurazioni lato client aggiornate e sono in grado di connettermi a questa cache, avvierò e testerò questo cluster di cache e il gioco è fatto. La configurazione del sito del mio server è completa a questo punto. Ragazzi, per favore fatemi sapere ci sono domande? Va bene, quindi, questo è iniziato. Farò clic con il pulsante destro del mouse e scelgo le statistiche.
Ron, ho una domanda qui davvero veloce NCache flussi per supportare le applicazioni Java per le sessioni JSP una cache di sessione o sono solo app ASP.NET? ok, è un'ottima domanda principalmente questo webinar era incentrato su ASP.NET, quindi mi sono concentrato maggiormente sul sito ASP.NET ma sì per rispondere a questa domanda NCache supportiamo completamente le applicazioni Java, abbiamo un client Java e quindi per le applicazioni Java, se hai sessioni web Java o sessioni JSP, potresti benissimo usare NCache. Quindi, il nostro provider rimane esattamente lo stesso, non è un'opzione di modifica del codice e abbiamo un'applicazione di esempio che viene installata NCache anche. Quindi, devi solo installare NCache su ambiente Windows oppure potresti anche usare container e quindi l'applicazione potrebbe essere su Windows o potrebbe essere anche su ambiente Linux UNIX, supporta completamente le applicazioni Java.
Monitora le statistiche della cache
Ho aperto le statistiche solo per vedere alcuni aspetti di monitoraggio, ho anche aperto uno strumento di monitoraggio che viene installato NCache. Eseguirò rapidamente un'applicazione dello strumento di stress test per verificare che la mia cache sia configurata correttamente e successivamente inizierò effettivamente con le applicazioni di esempio, un client è connesso, dovresti vedere dell'attività proprio qui, ecco qua e abbiamo dei contatori mostrando il valore delle richieste al secondo da entrambi i server e abbiamo già popolato alcuni grafici.
Quindi, ciò garantisce che tutto sia configurato correttamente e quindi possiamo iniziare con le nostre applicazioni di esempio.
Quindi, la prima applicazione di esempio è che queste sono cinque diverse ottimizzazioni. Parlerò di questi uno per uno e poi ti mostrerò le applicazioni di esempio. Prima di tutto, puoi usare NCache per la memorizzazione nella cache dei dati, abbiamo la nostra API dettagliata per i colli di bottiglia del database. Puoi utilizzare una cache distribuita in memoria veloce, è più veloce perché è in memoria, è più scalabile perché puoi aggiungere più server e quindi aumentare la capacità in fase di esecuzione aggiungendo più server. Puoi usarlo per lo stato della sessione, questa non è un'opzione di modifica del codice, le sessioni sono molto affidabili NCache poiché questi vengono replicati, le sessioni vengono gestite in un repository veloce e scalabile anche in confronto e non è necessario un bilanciamento del carico della sessione permanente. Parlerò di ulteriori vantaggi una volta che mostreremo effettivamente queste applicazioni di esempio, ma ti farò sapere che questi sono alcuni dei vantaggi che ottieni NCache subito non appena ti colleghi NCache per questi.
Per le web farm è possibile utilizzare lo stato di visualizzazione, è possibile memorizzare lo stato di visualizzazione sul lato server, non è necessario inviare lo stato di visualizzazione e si riduce anche la dimensione del payload dello stato di visualizzazione, quindi è possibile utilizzare NCache per SignalR Backplane, questa è la nostra quarta opzione e puoi anche usarla NCache per la memorizzazione nella cache di output e per il contenuto statico e questo vale anche per ASP.NET core. Puoi usarlo per lo stato della sessione all'interno di ASP.NET core e puoi anche usarlo per la memorizzazione nella cache delle risposte in ASP.NET core applicazioni.
Esempio di cache di sessione ASP.NET
Quindi, iniziamo con l'archiviazione dello stato della sessione ASP.NET. Questo è il più semplice di tutti, puoi configurarlo entro cinque minuti e puoi testarlo rapidamente. In effetti, ti mostrerò come configurarlo e poi iniziare con esso.
Quindi, questa è la nostra prima applicazione di esempio, quello che ho fatto è che viene installato NCache anche io ma l'ho leggermente modificato. Per la memorizzazione nella cache della sessione tutto ciò che devi fare è aggiungere un tag assembly, questi due assembly sono ridondanti, sono per un altro caso d'uso per la memorizzazione nella cache degli oggetti ma hai solo bisogno Alachisoft.NCache.Assemblaggio SessionStoreProvider. La versione 4.9 è l'ultima versione e quindi sono necessarie impostazioni cultura e token pubblici anche per questo assembly. Quindi, questo è un tipico riferimento a questo assembly dello stato della sessione, dopodiché è necessario sostituire il tag dello stato della sessione esistente con NCache. Se hai già un tag di stato della sessione devi sostituirlo, se non ne hai uno era InProc, in tal caso potresti effettivamente sostituirlo, puoi aggiungerlo come nuovo. Qui la modalità è personalizzata e il provider lo è NCacheSessionsProvider, il valore di timeout è se un oggetto sessione è in NCache rimane inattivo per più di venti minuti, scadrebbe automaticamente rimuoverlo dalla cache.
Poi ci sono alcune impostazioni come le eccezioni da abilitare. Quindi, questo può essere usato come tag di esempio, puoi copiarlo da qui e incollarlo nell'applicazione e quindi la cosa più importante è il nome della cache, devi solo specificare il nome della cache aspnetcache. Penso di usare lo stesso nome aspnetcache e risolverebbe le configurazioni per questo esempio perché specifichi solo il nome. Quindi, leggerebbe semplicemente le configurazioni per questa cache da client.ncconf aspnetcache o anche questo file può essere reso parte del progetto. Se hai un pacchetto NuGet, potresti effettivamente rendere anche questo file parte del tuo progetto e il gioco è fatto. Hai solo bisogno di salvare questo e lascia che lo crei come pagina principale perché stavamo usando due pagine qui e lo eseguirò e questo avvierebbe le sessioni di gioco guest per il provider e si collegherebbe a NCache per i dati della sessione.
Quindi, mi aspetto di creare un oggetto sessione nella cache e quindi leggerò alcuni dati dalla sessione e ti mostrerò anche l'oggetto sessione creato. Questa è un'applicazione per indovinare, ti consente di indovinare un numero compreso tra uno e cento e quindi stampa effettivamente il guest precedente dall'oggetto della sessione. Quindi, ha indovinato che il numero è compreso tra 0 e 23. Quindi, indovinerò solo 12, il numero è compreso tra 12 e 23. Quindi, ha letto anche l'ultimo numero. Supponiamo che il numero sia compreso tra 13 e 23. Quindi, indovineremo ancora una volta. Non sono in grado di indovinare, spero di arrivarci, ma solo per farti sapere che un oggetto sessione deve essere stato creato sul lato server.
Lascia che te lo mostri con l'aiuto di uno strumento ed eccolo lì, NCache test è una parola chiave che la aggiungo a questa applicazione di esempio. Se lo cambio, questo è per distinguere tra sessioni di applicazioni diverse, potrebbe esserci uno scenario in cui hai due applicazioni e utilizzerai la stessa cache per entrambe le applicazioni. Quindi, in tal caso puoi avere un ID app aggiunto alla variabile di sessione, ma in genere un'applicazione dovrebbe memorizzare nella cache la sua sessione in una cache dedicata. Quindi, non importa, se la specifichi anche come una stringa vuota ma questa è stata creata e questo è il tuo ID di sessione ASP.NET, la sessione qui viene replicata proprio qui. Quindi, se questo server si interrompe, i dati della sessione vengono resi disponibili automaticamente.
Alcuni vantaggi in più di NCache lo stato della sessione rispetto a InProc è fuori processo, quindi il tuo processo web è completamente senza stato. Quindi, come preferito dal protocollo HTTP, è più scalabile, puoi aggiungere più risorse, è più veloce perché è in memoria, è paragonabile a InProc e quindi è molto affidabile. Se un server si interrompe non devi preoccuparti di nulla e, soprattutto, non devi più utilizzare sessioni appiccicose o bilanciamento. Puoi avere lo stesso bilanciamento del carico e la richiesta può rimbalzare da un server Web all'altro. Non devi preoccuparti di nulla perché i server Web non memorizzano nulla, gli oggetti della sessione effettivi sono archiviati NCache e questo è un archivio di processo esterno per le tue applicazioni e confronti di StateServer. Non è un singolo punto di errore, se un server si interrompe o lo si interrompe per manutenzione, non devi preoccuparti di nulla, funzionerebbe senza problemi.
In secondo luogo, è molto scalabile, puoi aggiungere più server al volo. È molto affidabile, è molto scalabile, è veloce in confronto. Per il database non è lento, è veloce ed è molto scalabile e in alcuni casi è anche migliore in termini di affidabilità dove non si dispone della replica per i database. Quindi, questo lo copre e un'altra caratteristica importante all'interno NCache è il nostro supporto per sessioni multisito, questa è un'altra caratteristica sessioni multiregione, in cui avrai sessioni di due diverse regioni archiviate NCache e puoi avere sessioni completamente sincronizzate.
Se una richiesta di sessione viene rimbalzata da un server all'altro o da una regione all'altra, è stata automaticamente alimentata nella sessione in tutta la regione e portata qui e viceversa. Quindi, se hai bisogno di portare il lato verso il basso, puoi instradare tutto il tuo traffico sull'altro lato mantenendo la cache in esecuzione per un certo periodo di tempo. Quindi, questa è un'altra caratteristica. Una delle nostre principali compagnie aeree, il cliente delle compagnie aeree sta effettivamente utilizzando questa funzione per l'affinità di posizione. Quindi, questo copre il nostro stato di sessione ASP.NET. Questo non è un fornitore di modifiche al codice, per favore fammi sapere se ci sono domande al riguardo, ho già risposto a una domanda sulle sessioni JSP, puoi usare NCache anche per sessioni web basate su Java. Ammesso che non ci siano domande.
ASP.NET View State Esempio di memorizzazione nella cache
Successivamente, parlerò dello stato di visualizzazione, ora NCache ha anche un provider dello stato di visualizzazione, il modo in cui funziona è fondamentalmente che manteniamo lo stato di visualizzazione sul lato server. È di nuovo un provider, tutto ciò che devi fare è impostare correttamente un gruppo di sezioni, sono le impostazioni del contenuto, è ContentOptimization.Configurations.ContentSettings. Il nome del gruppo di sezioni è nContentOptimization e quindi questo ha alcune impostazioni in cui prendi un nome di cache, ad esempio, sto usando mycache in questo momento, il modo in cui abbiamo progettato il nostro ASP.NET view state provider è che manteniamo lo stato di visualizzazione sul lato server a destra. Quindi, prima di tutto eseguirò senza memorizzare nella cache anche se ho collegato il provider precedente ma ho impostato la memorizzazione nella cache dello stato di visualizzazione in modo che sia falsa e lo eseguirò e ti mostrerò lo stato di visualizzazione effettivo che torna indietro al browser.
Quindi, ti mostrerò l'opzione predefinita e poi ti mostrerò la NCache visualizza lo stato e confronteremo la differenza. Quindi, ci sono alcune pagine web farm e ti mostrerò l'origine della pagina di visualizzazione.
Questo è lo stato di visualizzazione predefinito, la parte del valore, lasciami portare qui e lasciami creare un documento temporaneo qui. Ora questo è lo stato di visualizzazione predefinito che fa parte del mio pacchetto di risposta e quando respingo questa pagina, farà anche parte del mio pacchetto di richiesta. Questa è una richiesta individuale e nota quanti caratteri sono stati aggiunti alle intestazioni di richiesta e risposta a destra e questo è lo stesso per tutte le richieste che farò. Lascia che ti mostri solo qualche altra richiesta e lascia che ti mostri anche la fonte della pagina di visualizzazione di questa.
Quindi, è quasi simile che potresti vedere sullo schermo. Ora con NCache quello che abbiamo fatto è intercettare il tuo stato di visualizzazione con l'aiuto del nostro provider di stato di visualizzazione. Manteniamo lo stato di visualizzazione sull'estremità del server, quindi, questa parte del valore creiamo una chiave e un valore per una determinata pagina della web farm, l'abbiamo archiviata sull'estremità del server, ora è archiviata sull'estremità del server, quindi inviamo un piccolo token torna al browser. Quindi, questo è un token di dimensione statica, che viene rispedito al browser. Non cambia mai davvero, verrà sempre inviato lì e poi riportato per essere riutilizzato e quando rispondi, in realtà effettui una chiamata a NCache e recuperare lo stato di visualizzazione extra da NCache e quindi utilizzarlo nella tua web farm per visualizzare effettivamente lo stato ed è quello che stiamo facendo dietro le quinte.
I vantaggi che ottieni dal tuo pacchetto dello stato di visualizzazione diventano di dimensioni inferiori proprio perché è un token. Quindi, ciò ha un impatto complessivo sulla riduzione delle dimensioni del carico utile per la richiesta e la risposta. Quindi, questo migliora le tue prestazioni e in secondo luogo, se hai centinaia di kilobyte di stato di visualizzazione che viaggiano avanti e indietro per migliaia di richieste, consumerà la tua larghezza di banda. S, questo non accadrà con NCache, NCache lo stato di visualizzazione è un token statico e ti mostrerò il token molto velocemente.
Ron, lasciami saltare per la domanda, davvero veloce NCache hai delle funzionalità di sicurezza della fattura come la crittografia per le sessioni e la visualizzazione della cache dello stato? sì, queste sono funzionalità che puoi impostare in modo esplicito, queste sono generali NCache caratteristiche. Quindi, tutto lo stato di visualizzazione è già una stringa crittografata, ma se vuoi crittografare ulteriormente e fammi vedere se è in giro sì, puoi abilitare la crittografia sulla cache stessa devi interromperla, impostare la crittografia, abbiamo provider DES , disponiamo di provider AES, disponiamo di client FIPS, conformi a FIPS, provider DES AES. Quindi, sì, puoi semplicemente impostare questo e tutto il carico utile dai server client verrebbe crittografato e decrittografato rispettivamente qui e recuperato. Quindi, questo è qualcosa che puoi impostare su richiesta e puoi far andare le cose e con questa domanda, voglio anche evidenziarlo poiché NCache non sta memorizzando questo è lo stato di visualizzazione successivo NCache è stato collegato è stato collegato come provider e nota la differenza, sono questi molti caratteri rispetto a questi molti caratteri. Quindi, questa è la tua impostazione predefinita, questa è con NCache e osserva tu stesso la differenza, questo rallenta, riduce la dimensione del carico utile su tutti gli aumenti delle prestazioni, i costi di virtualizzazione della banda diminuiscono. Quindi, vedi molti miglioramenti nell'architettura e, soprattutto, il tuo stato di visualizzazione effettivo non viene mai più restituito al browser. Verrà archiviato sul lato server, è sicuro in generale.
Quindi, sulla base di questa domanda, grazie per averlo chiesto NCache lo stato di visualizzazione è per impostazione predefinita più sicuro dell'opzione predefinita perché lo memorizziamo sul lato server, dove è effettivamente necessario. Quindi, spero che aiuti. Ho intenzione di chiudere questo, tutte le domande sullo stato di visualizzazione, altrimenti passerò al nostro prossimo segmento.
Esempio di memorizzazione nella cache dei dati dell'applicazione
Lascia che ti mostri prima la memorizzazione nella cache degli oggetti a causa del vincolo di tempo. Penso che dovrei occuparmi prima di questo. Per i colli di bottiglia del database, tutto ciò che memorizza nel database che rallenta le cose in alternativa puoi utilizzare una cache distribuita come NCache. Questo è NCache API qui.
Connessione cacheCache cache = NCache.InitializeCache("myCache");
cache.Dispose();
Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");Ecco come connetti la cache, ecco come smaltisci l'handle verso la fine delle operazioni, tutto è archiviato in una coppia di valori chiave, è un oggetto consentito da .NET con valore chiave stringa su cui puoi mappare le tue tabelle di dati sui tuoi oggetti di dominio e quindi memorizzi i tuoi oggetti di dominio e quindi gestisci gli oggetti di dominio archiviando singoli oggetti o raccolte che hanno relazioni, ricerche SQL l'elenco continua ma questa è un'operazione di base di creazione, lettura, aggiornamento, eliminazione.
Eseguirò rapidamente un'applicazione di esempio e dimostrerò come la useresti effettivamente NCache per la memorizzazione nella cache degli oggetti. Hai bisogno di questi due riferimenti riassuntivi Alachisoft.NCache.Web e Alachisoft.NCache.Durata. Una volta che hai fatto questo, lascia che lo crei come una pagina iniziale e ti mostri il codice dietro per questo. Questa è una web farm ASP.NET ma se hai controller MVC potresti anche usare lo stesso approccio e quindi ho questo spazio dei nomi proprio qui e all'interno di questa applicazione, sto inizializzando mycache, devi specificare il nome della cache e potresti anche specificare i server qui, usando InitParams nella cache di destra InitParams proprio qui o potresti semplicemente specificare il nome e risolvere il nome tramite client.ncconf che ti ho mostrato in precedenza. C'è un addObject, che aggiunge un cliente, il nome è David Jones, maschio, numero di contatto, questo è l'indirizzo e poi chiamo cache.Add.
Allo stesso modo, lo sto inserendo modificando la pagina o potrei effettivamente anche cambiare anche il nome solo per assicurarmi che questo sia aggiornato e quindi sto chiamando cache.Insert e poi riavrò l'oggetto, ottenendo il conteggio dell'oggetto. Sto rimuovendo quell'oggetto, sto solo eseguendo un test di carico. 100 articoli verranno aggiornati ancora e ancora. Quindi, eseguiamo l'applicazione di esempio, è così intuitivo iniziare con essa e avvierà semplicemente l'applicazione e sarò in grado di eseguire tutte queste operazioni per te e prima di farlo effettivamente, vorrei anche per mostrarti gli stati di visualizzazione che sono stati memorizzati nella cache NCache.
Potresti vedere le chiavi per lo stato di visualizzazione per tre pagine e questa è la chiave effettiva dell'oggetto e quindi lo stato di visualizzazione effettivo è sulla parte del valore. Ho dimenticato di menzionarlo ora, supponendo che mi sia consentito solo cancellare il contenuto. Quindi, che ora abbiamo a che fare solo con i dati di memorizzazione nella cache degli oggetti, in realtà lascia che lo faccia semplicemente dal manager, è conveniente. Quindi, aggiungerò un oggetto, il cliente ha aggiunto, riprenderò questo oggetto. Quindi, abbiamo David Jones, 23 anni. Lo aggiornerò e poi lo aggiungerò, lo riprenderò ora è David Jones 2 e poi abbiamo 50 anni come età, prendilo di nuovo, elementi nella cache 1, rimuoverò questo oggetto di nuovo elementi nella cache 0 inserirlo ancora una volta, inserire è in aggiunta anche recuperare l'oggetto e quindi posso mostrartelo nella cache. Quindi, a questo punto avevo a che fare con un oggetto e la chiave era il cliente a nome del cliente aggiunto ad esso e quindi inizierò il carico, testerò ora. Vedresti alcune attività nella cache, ci sono richieste in arrivo e hai richieste client che gestiscono i dati.
E se eseguo semplicemente di nuovo queste chiavi della cache di dump, mi mostrerebbe semplicemente le cento chiavi scaricate insieme. Quindi, queste sono le chiavi che ho aggiunto. Quindi, ecco com'è semplice iniziare con la memorizzazione nella cache degli oggetti, qualsiasi dato che appartiene al database e rallenta le cose, limita la tua scalabilità a cui puoi portarlo NCache usando la nostra cache degli oggetti. Potrebbe essere qualsiasi cosa, oggetti di dominio, raccolte, set di dati, immagini, qualsiasi tipo di dato relativo all'applicazione può essere memorizzato nella cache utilizzando il modello di memorizzazione nella cache degli oggetti. Spero che questo aiuti, lasciami iniziare con questo, va bene, questo copre la nostra memorizzazione nella cache dei dati, dopo che ci sono SignalR Backplane.
ASP.NET SignalR Backplane Campione
Parliamone Segnale R. Con NCache abbiamo un potente messaggistica pub/sub piattaforma. Quindi, abbiamo un'applicazione di esempio e questa ti mostrerò anche i pacchetti NuGet. NCache le librerie vengono installate con l'installazione oppure puoi usare i nostri pacchetti NuGet. Quindi, se vai al nostro repository NuGet online e cerchi NCache, vedrai tutti i pacchetti NuGet. Alachisoft.NCache.SDK è per la memorizzazione nella cache degli oggetti, Linq per la query linq, abbiamo il provider dello stato della sessione, quindi abbiamo anche open source e community.
Questo è il pacchetto NuGet che ho incluso in questa applicazione. Basta compilarlo e vedere se funziona correttamente perché dovrebbe avere un pacchetto NuGet aggiunto. Va bene, per SignalR Backplane tutto ciò che devi fare è assicurarti di aver aggiunto il pacchetto SignalR NuGet, voglio dire che questo è installato se non è già installato, va bene. Quindi, hai aggiunto un pacchetto NuGet e dopo che devi aggiungere, ha aggiunto alcuni assembly SignalR secondo necessità e anche alcuni assembly di supporto e successivamente se vai su web.config, ho appena aggiunto alcune impostazioni lì il mio nome della cache è aspnetcache a destra e poi la chiave dell'evento, che è il nome dell'argomento che ti piace per questo. Quindi, in realtà vorresti fornire un nome dell'argomento in base al quale desideri che vengano trasmessi messaggi di chat SignalR o messaggi di SignalR per questa particolare applicazione di chat e quindi tutto ciò che devi fare è modificare una riga di codice all'interno in cui specifichi il il nome della cache e la chiave dell'evento e punta a parole NCache ed eseguire l'applicazione di esempio. Userebbe automaticamente NCache per il backplan di SignalR, NCache diventa il tuo backplan, ecco com'è semplice collegarlo NCache per l'applicazione SignalR.
Vantaggi che ottieni a differenza di .NET nativo Redis è veloce, scalabile, affidabile rispetto ai database e ai bus di messaggi e quindi abbiamo un modello pub/sub completamente funzionante e completamente supportato, che lo supporta. Quindi, puoi anche utilizzare direttamente la messaggistica pub/sub, ma un'estensione di quel caso d'uso della messaggistica pub/sub è la nostra SignalR Backplane ed è anche abbastanza facile da configurare.
Quindi, questa applicazione è iniziata. Dovrebbe esserci una chiave qui, penso che sia difficile trovare la chiave ma solo per mostrarti la chat NCache, funziona e lo trasmetterò a un altro browser firmando un altro utente, diciamo Nick. Se lo riporto indietro, potresti vedere che ha effettivamente trasmesso il messaggio anche all'altro client connesso. Quindi, ecco com'è facile. Lasciami chiedere un'altra volta e poi controlla se funziona come previsto, quindi ecco fatto. Quindi, questo viene guidato NCache ed è molto facile da configurare ed è così che configuri e l'ultima funzione all'interno NCache, il quinto booster è la memorizzazione nella cache di output.
Ron, ho una domanda su SignalR, i nostri messaggi SignalR archiviati come oggetto visivo all'interno NCache o fa NCache utilizzare la notifica per questo? NCache utilizza la notifica pub/sub per questo. Quindi, abbiamo una piattaforma di messaggistica pub/sub che è in background, nella cache stessa vedresti solo un oggetto o non vedrai nemmeno l'oggetto perché è un argomento. Quindi, c'è un argomento che viene creato, è un tunnel logico in cui sono collegati più processi di lavoro e trasmettono effettivamente NCache, tutti i messaggi SignalR a quell'argomento. Quindi, è un framework di notifica se stai chiedendo, se vedresti molti messaggi aggiunti nella cache, no, vedresti solo un argomento e quindi ci sono messaggi all'interno dell'argomento. Ci sono alcune statistiche negli incontri popper che puoi visualizzare per vedere quanti messaggi ci sono all'interno dell'argomento ma per quanto riguarda i singoli oggetti, non vedrai quegli oggetti, vedrai solo un oggetto come argomento. Spero che aiuti.
Esempio di memorizzazione nella cache di output ASP.NET
Caratteristica finale all'interno di questo, penso che siamo anche a corto di tempo, lo affronterò rapidamente. È la nostra cache di output a cui devi solo impostare la sezione di cache di output, a cui devi fare riferimento NCache dll del provider della cache di output. Questo è proprio qui, hai bisogno di questi riferimenti Ncache.Adattatori, web, runtime nella cache e successivamente fai semplicemente riferimento al provider della cache di output N e quindi imposti il nome della cache su aspnetcache, la versione dovrebbe essere l'ultima. Il modo in cui funziona è che in realtà memorizza nella cache l'output delle pagine statiche, lo esegui semplicemente e quindi memorizza nella cache solo l'output di una pagina statica. Se è l'intera pagina o porzioni all'interno della pagina che sono statiche e decori le tue pagine statiche con questa cache di output della direttiva, specifica una durata, una posizione e VaryByParam. Se questi parametri non cambiano, significa automaticamente che si tratta dello stesso output.
Quindi, l'output memorizzato nella cache viene presentato agli utenti finali, non è necessario eseguire le pagine, non è necessario coinvolgere i database, alleggerire il carico dei processi di lavoro, scaricare il database, risparmiare CPU costose e risorse della macchina e ottieni un output di pagina pronto reso disponibile per i tuoi clienti finali. Quindi, nel complesso migliora le tue prestazioni, ASP.NET fornisce questo come funzionalità e NCache lo porta a un livello distribuito in cui abbiamo un output di pagina molto scalabile, molto veloce e molto affidabile archiviato NCache senza modifiche al codice e questo vale per ASP.NET core inoltre, potresti usare nel modo in cui puoi usare NCache all'interno dell'ASP.NET core anche applicazioni web. Abbiamo fatto un webinar separato su questo e se abbiamo la cache idistribuita, abbiamo l'archiviazione della sessione e quindi abbiamo anche ASP.NET core memorizzazione nella cache della risposta e memorizzazione nella cache principale di EF.
Quindi, queste sono alcune delle caratteristiche che volevo evidenziare, questo completa i nostri cinque booster di prestazioni. Spero che vi sia piaciuto, per favore fatemi sapere se ci sono altre domande, penso che siamo anche a corto di tempo. Quindi, se ci sono altre domande ora è il momento di porre quelle domande, quindi per favore fatemelo sapere.
In generale, vorrei menzionare anche questo NCache è un cluster di cache dinamica al cento per cento completamente elastico, senza un singolo punto di errore. Abbiamo molte topologie e funzionalità come crittografia, sicurezza, compressione, avvisi e-mail, sincronizzazione database, ricerche simili a SQL, query continue, modello pub/sub, dati relazionali in NCache, questi sono tutti coperti come parte di diverse funzionalità. Quindi, se ci sono domande specifiche su queste, sentiti libero di porre anche quelle domande, altrimenti lo concluderò e lo consegnerò a Nick.
Grazie mille Ron, un'ultima domanda qui è possibile impostare un provider personalizzato per la memorizzazione nella cache della sessione NCache? NCache è già un provider personalizzato. NCache si trova in un provider personalizzato, le modalità predefinite sono InProc, State Server o SQL Server e quindi la quarta modalità di ASP.NET è personalizzata. Così, NCache provider stesso è un provider personalizzato. Sono leggermente confuso sulla domanda se ci sono requisiti specifici in merito, per favore fatemi sapere altrimenti NCache stesso è un provider personalizzato per ASP.NET.
Ok, grazie mille Ron, se non ci sono altre domande, vorrei ringraziare tutti per essere venuti e essersi uniti a noi oggi e grazie ancora Ron per la vostra preziosa intuizione in merito e ragazzi, se avete domande potete sempre contattarci inviandoci e-mail A support@alachisoft.com. Mettiti in contatto con il nostro team di vendita inviandoci un'e-mail all'indirizzo sales@alachisoft.com e qualcuno del team di vendita sarà felice di lavorare con te e assicurarsi che tutte le tue domande abbiano una risposta, fornire tutte le informazioni di cui hai bisogno e con ciò ti suggerirei anche di scaricare una versione di prova dal nostro sito Web di NCache, viene fornito con una prova di 30 giorni. Abbiamo anche una mediazione che ha un'opzione di supporto a pagamento e un'edizione open source gratuita, tredici anni con così tanti contenuti. Grazie a tutti per esservi uniti a noi e ci vediamo la prossima volta grazie.