Campo di codice di Orlando 2019

Ottimizza ASP.NET Core Prestazioni con cache distribuita

Di Iqbal Khan
Presidente ed evangelista tecnologico

ASP.NET Core sta rapidamente diventando popolare per lo sviluppo di applicazioni Web ad alto traffico. Scopri come ottimizzare ASP.NET Core prestazioni per la gestione di carichi di transazione estremi senza rallentamenti utilizzando una cache distribuita .NET open source. Questo discorso copre:

Panoramica rapida di ASP.NET Core colli di bottiglia delle prestazioni
Panoramica della cache distribuita e di come risolve i problemi di prestazioni
Dove puoi utilizzare la cache distribuita nelle tue applicazioni
Alcune importanti funzionalità della cache distribuita
Esempi pratici utilizzando Open Source NCache come cache distribuita

Tratterò questo argomento su come ottimizzare ASP.NET core prestazioni e userò la cache distribuita come tecnica per apportare quei miglioramenti e che userò NCache come l'esempio in questo.

ASP.NET Core Popolari (app ad alto traffico)

Sappiamo tutti che ASP.NET core è il nuovo .NET core, l'architettura pulita e leggera, multipiattaforma e open source e questo sta diventando uno dei motivi principali per cui sempre più persone si stanno spostando verso ASP.NET core.

Inoltre, esiste un'enorme base di utenti ASP.NET legacy e soprattutto se sei un'applicazione ASP.NET MVC, quindi passa ad ASP.NET core è piuttosto semplice. Se non sei un MVC allora, ovviamente, hai molto codice che devi scrivere per fare. Quindi, tutti questi sono i motivi per cui sono sicuro che sei qui anche perché ASP.NET core è la scelta .NET leader per la realizzazione di applicazioni web.

ASP.NET Core Ha bisogno di scalabilità

Quindi, quando hai ASP.NET core viene utilizzato sempre di più in situazioni di traffico intenso. Traffico elevato di solito significa che hai un'applicazione rivolta al cliente. Potresti essere un'attività online, potresti essere un'attività di vendita al dettaglio. C'è una miriade di industrie, assistenza sanitaria, e-government, social media, scommesse online, gioco d'azzardo, tutto ciò a cui puoi pensare. Tutti sono online in questi giorni. Quindi, chiunque! Quando c'è un'applicazione web ASP.NET core viene utilizzato che significa ASP.NET core deve essere scalabile.

Che cos'è la scalabilità?

Cosa significa? Lascia che lo definisca, sono sicuro che ne sai molto, ma solo per motivi di completezza, definirò solo la terminologia.

Quindi, scalabilità significa che se hai un'applicazione che con cinque utenti hai un tempo di risposta davvero buono, fai clic su di essa e in un secondo o due la pagina torna indietro. Quindi, se puoi ottenere lo stesso tempo di risposta con cinquemila o cinquantamila o cinquecentomila utenti, la tua applicazione è scalabile. Se non puoi, allora non sei scalabile. Se non hai prestazioni elevate con cinque utenti, devi andare ad altre discussioni su come hai scritto il tuo codice. Ma presumo che la tua applicazione sia sviluppata con buoni algoritmi, con un buon approccio ed è un'applicazione ad alte prestazioni con cinque utenti. Quindi, come renderlo ad alte prestazioni con carichi di picco?

Che cos'è la scalabilità lineare?

Quindi, se puoi passare da cinque a cinquemila a cinquantamila, si chiama scalabilità lineare.

E il modo in cui lo ottieni, come sai in un ambiente con bilanciamento del carico, distribuisci ASP.NET core applicazione con un sistema di bilanciamento del carico e si aggiungono sempre più server. Quindi, quando aggiungi più server, qui, la tua capacità di transazione, il numero di richieste al secondo aumenta in modo lineare. Se riesci a raggiungere questo obiettivo, sarai in grado di ottenere la stessa prestazione. E questo è l'obiettivo del discorso di oggi che vogliamo essere in grado di raggiungere queste prestazioni elevate con carichi di picco. Quindi, se non hai un'alta prestazione sotto carico di picco, se non hai un'applicazione lineare significa che hai dei colli di bottiglia, da qualche parte. Quindi, non appena superi una certa soglia, non importa se aggiungi più caselle. In realtà, probabilmente rallenterà le cose perché c'è un collo di bottiglia da qualche parte che impedisce la tua applicazione. Quindi, sicuramente non vuoi essere una scalabilità non lineare.

Quali app necessitano di scalabilità?

Per ricapitolare, quali tipi di applicazioni devono essere scalabili?

Ovviamente, ASP.NET core che è ciò di cui stiamo parlando. Potresti anche disporre di servizi Web, il che significa che le app ASP.NET sono le app Web che significano che i loro utenti sono esseri umani. I servizi Web sono di nuovo app Web. I loro utenti sono altre app. I microservizi sono un concetto relativamente nuovo che vale anche per le applicazioni lato server. Ovviamente, ciò comporta la riprogettazione dell'intera applicazione. Non ho intenzione di entrare nel modo in cui lo fai. Sto solo menzionando l'applicazione dei tipi in modo che possiate mappare qualsiasi cosa voi ragazzi stiate facendo o la vostra azienda stia facendo la mappa in questo o meno. E infine, molte applicazioni server solo generiche. Queste applicazioni server potrebbero eseguire l'elaborazione batch. Ad esempio, se sei una grande azienda, diciamo, se sei una banca potresti dover elaborare molte cose in background in modalità batch, in modalità flusso di lavoro e quelle sono le app del server.

Il problema e la soluzione della scalabilità

Quindi, tutti questi diversi tipi di applicazioni devono essere in grado di gestire la scalabilità, il che significa che devono essere in grado di elaborare tutti quei carichi di transazione in aumento senza rallentamenti. Quindi, c'è ovviamente un problema di scalabilità, altrimenti non avremmo questa conversazione. Se tutto è andato bene, la buona notizia è che il tuo livello di applicazione non è il problema, il tuo ASP.NET core l'applicazione non è il problema, è l'archiviazione dei dati. Qualunque dato tu stia toccando, qualunque cosa, non importa, questo sta causando un collo di bottiglia nelle prestazioni. E questi sono i tuoi database relazionali, i tuoi dati legacy del mainframe e un sacco di altri dati. È interessante notare che NoSQL databaseNon sono sempre la risposta perché in molte situazioni non sei in grado di… perché NoSQL database ti chiede di abbandonare il tuo database relazionale e passare a un nuovo database SQL o NoSQL database cosa che non sei in grado di fare per una serie di motivi tecnici e non. E, se non sei in grado di passare a NoSQL database, a che serve? Giusto?

Quindi, il mio obiettivo è che devi risolvere questo problema con il database relazionale nella foto perché questo è il database che dovrai utilizzare, come ho detto, per una serie di motivi. E, se non sei in grado di allontanarti da esso, allora NoSQL databases non sono la risposta in molte situazioni.

Distribuzione cache distribuita

Pertanto, dovresti continuare a utilizzare un database relazionale e distribuire invece una cache distribuita nella tua applicazione.

Ecco come appare. Quindi, se vedi che hai lo stesso livello di applicazione, puoi aggiungere sempre più server man mano che il carico di transazione aumenta. Nel caso di molti di questi, diciamo app Web e servizi Web, di solito sono un sistema di bilanciamento del carico al di sopra del quale si assicura che ogni server Web riceva lo stesso carico dagli utenti. Nel caso di applicazioni server, potrebbe non avere molto bilanciamento, potrebbe dipendere dalla natura dell'applicazione. Ma il fatto è che puoi aggiungere sempre più server e qui c'è solo un database. E, come ho detto, potrebbero essercene alcuni NoSQL database per alcuni dati speciali più piccoli, ma la maggior parte dei dati è ancora relazionale. Quindi, l'obiettivo è quello di inserire un livello di memorizzazione nella cache e una cache distribuita è essenzialmente un cluster di due o più server e questi server sono server a basso costo. Questi non sono server di tipo database di fascia alta e tutto è archiviato in memoria.

Perché in memoria? Perché la memoria è molto più veloce del disco rigido. Se la tua applicazione ha bisogno di prestazioni sempre maggiori, devi essere assolutamente chiaro su questo. Il disco rigido, che sia SSD o HDD, ti ucciderà. Devi andare a memoria. Tutto deve essere archiviato in memoria, altrimenti non otterrai le prestazioni che desideri. E questo indipendentemente dal fatto che tu vada a una cache distribuita o meno, ma in memoria è questo lo spazio di archiviazione. Quindi, una cache distribuita ha due o più server. Forma un cluster e la parola cluster significa che ogni server conosce l'altro server nel cluster, ha raggruppato le risorse, la memoria, la CPU e la scheda di rete. Quindi, queste sono le tre risorse che riunisce in un'unica capacità logica.

Memoria, perché ogni server ha RAM, quindi una configurazione tipica che abbiamo visto utilizzare dai nostri clienti è compresa tra 16 e 32 giga di RAM e ogni server Cache. è un minimo di 16 noi consigliamo, tra 16 e 32. E poi, invece di andare sopra 32 a, diciamo 64 o 128 giga di RAM, in ogni box che poi richiede di aumentare la capacità della CPU perché più memoria hai il più raccolta dei rifiuti che devi fare. Poiché .NET utilizza GC, quindi più raccolta di dati inutili significa più CPU, altrimenti la raccolta di dati inutili diventa il collo di bottiglia. Quindi, è meglio avere una gamma da 16 a 32 e non più grande e avere solo più scatole che avere 128 giga di due scatole. Quindi, è per questo che serve la memoria.

La CPU ovviamente è la seconda cosa. Anche in questo caso, la configurazione tipica è di circa 8 core. Alcune delle implementazioni di fascia alta utilizzererebbero circa 16 core, ma 8 core sono abbastanza buoni per scatola. Come ho detto, server a basso costo. E la scheda di rete, ovviamente, perché tutti i dati inviati da qui a qui vengono inviati tramite le schede di rete. Ora sul livello dell'applicazione, hai ovviamente più server delle applicazioni rispetto ai server della cache. E ancora, di solito quello che consigliamo è un rapporto di quattro a uno o cinque a uno. Cinque server delle applicazioni su un server cache con un minimo di due server cache. Quindi, se hai cinque server di applicazioni qui, hanno cinque schede di rete, inviano dati a un rapporto di cinque a uno di schede di rete.

Quindi, la scheda di rete, devi avere almeno una scheda di rete gigabit o 10 gigabit nei server cache. A parte questo, devi solo metterli insieme e diciamo che inizi con due come minimo e quando ne hai raggiunti due al massimo, quello che accadrà è che lo sottoscrivi, eseguirai la tua applicazione. Tutto funzionerà molto velocemente o forse stai eseguendo test di carico. Tutto funzionerà super veloce e il carico maggiore. Improvvisamente il lato server inizierà a vedere una maggiore CPU, un maggiore consumo di memoria e il tempo di risposta inizierà a rallentare. Ora questo è ciò che accadrà con il database relazionale tranne che qui puoi aggiungere una terza casella e improvvisamente ottieni un altro grande sollievo e ora inizierai di nuovo con un throughput più elevato e ora puoi aggiungere sempre più transazioni inizierà a raggiungere il picco fuori e poi aggiungi una quarta casella, lo sai.

Quindi, è così che questa immagine continua ad aumentare e questo non diventa mai un collo di bottiglia questo, e Never Say Never, ma quasi mai, diventa un collo di bottiglia perché puoi aggiungere sempre più server. E, quando aggiungi più server qui, ne aggiungi semplicemente altri in questa cache qui che non puoi fare con il database. Ora, ho caricato 8020. In realtà, è più come se il 90% del traffico vada alla cache il 10% vada al database perché sempre più dati verranno letti dalla cache. Esaminerò alcuni altri aspetti che una cache deve gestire, ma questa è fondamentalmente un'immagine, questo è il motivo per cui hai bisogno di una cache distribuita.

Utilizzo della cache distribuita

Bene! Quindi, andiamo avanti. Ora che spero di averti convinto che devi incorporare a cache distribuita nella tua applicazione che la prima domanda che viene in mente è, beh, cosa devo fare con esso? Come lo uso? Quindi, ci sono tre categorie principali in cui puoi utilizzare una cache distribuita.

Ce ne sono altri ma per la maggior parte della discussione ce ne sono tre davvero di alto livello.

Memorizzazione nella cache dei dati dell'app

Il numero uno è la memorizzazione nella cache dei dati dell'applicazione. Questo è ciò di cui ho parlato fino ad ora. Qualunque siano i dati nel database, è quello che chiamo dati dell'applicazione, li stai memorizzando nella cache in modo da non andare al database. Ora, tieni presente, e con ciascuno di questi, con un'applicazione che memorizza nella cache i dati, la natura del problema è che i dati esistono in due posti; la cache e il database. E, ogni volta che i dati esistono in due posti, cosa potrebbe andare storto? Fuori sincrono! Sì! Quindi, i dati potrebbero non essere sincronizzati. Quindi, se i tuoi dati e la cache non erano sincronizzati dal database, ciò potrebbe creare molti problemi. Potrei prelevare un milione di dollari due volte supponendo di doverlo cominciare, ma, diciamo così... Questo è il primo problema che mi viene in mente.

Qualsiasi cache, qualsiasi cache distribuita che non è in grado di gestire quel problema, significa che sei limitato ai dati di sola lettura. Ma quelli che chiamiamo dati di riferimento. Ed è così che è iniziata la memorizzazione nella cache per essere compresi nella cache dei dati di sola lettura delle mie tabelle di ricerca. La tabella di ricerca è circa il 10% dei tuoi dati. In alcune applicazioni non è che un'applicazione media. Il 90% dei tuoi dati non sono dati di ricerca. Sono dati transazionali. Sono i tuoi clienti, le tue attività, i tuoi ordini, tutto. Quindi, se non sei in grado di memorizzare nella cache tutti quelli, allora il vantaggio, diciamo il 10% dei dati, forse la ricerca viene davvero eseguita più della sua giusta quota. Quindi, quel 10% potrebbe darti il vantaggio del 30% ma hai ancora il 70% dei dati che devi andare al database. Ma se potessi memorizzare nella cache tutti i dati, cosa che saresti in grado di fare solo se ottieni quel comfort, otterrai il vero vantaggio.

ASP.NET Core Memorizzazione nella cache specifica

Il secondo caso d'uso o il secondo modo di usare Is, quello che chiamo ASP.NET core cache specifica e ci sono tre modi. Una è la sessione che è la più comunemente compresa. ASP.NET li aveva ASP.NET core li ha. Sono qui per restare. Non credo che le sessioni andranno via, anche se alcune persone sostengono che non dovremmo usare le sessioni. Non c'è nessun danno se li usi. L'unico problema con loro è che dove li immagazzini. Questo è sempre stato il problema con ASP.NET. Qualunque sia l'opzione di archiviazione fornita da Microsoft, era piena di problemi. Quindi, l'unica opzione in quel momento era utilizzare una cache distribuita che fortunatamente potevi collegare come opzione personalizzata ai tempi di ASP.NET. In ASP.NET core, Microsoft non ha un built-in o hanno un'immagine come un in-memory autonomo ma entrano subito in un IDistributedCache o provider di sessioni personalizzate che puoi collegare a una cache distribuita di terze parti come NCache.

Sessions è la prima, la seconda è la memorizzazione nella cache delle risposte. Stavo per dire chi non sa della memorizzazione nella cache delle risposte, ma non è un buon modo per chiedere. La memorizzazione nella cache delle risposte è come una versione più recente della cache di output, ma è più basata su standard. È l'output della pagina che puoi memorizzare nella cache e lo esaminerò, ma è anche qualcosa che puoi memorizzare nella cache e collegare una cache distribuita come middleware per esso.

E il terzo è se hai un segnale o un'applicazione che è l'app web live. Le app web live sono quelle in cui, diciamo, se hai un'applicazione di trading azionario che ha bisogno di propagare costantemente tutte le variazioni del prezzo delle azioni e ha centinaia di migliaia di clienti. Sono tutti connessi, quindi rimarranno tutti connessi alla memorizzazione nella cache o ai livelli dell'applicazione. È diverso dal normale HTTP in cui per ogni richiesta Web è aperta una nuova connessione socket. Qui, la connessione socket rimane aperta e gli eventi vengono propagati dal server. Quindi, in un SignalR, quando hai una transazione più alta, un gran numero di utenti, devi avere un modulo web con bilanciamento del carico ma poiché i socket sono mantenuti aperti, quindi ogni server parlerà con il proprio client ma ora che tutti i i client o tutti i server hanno set di client diversi, quindi devono condividere i dati. Quindi, quei dati vengono condivisi attraverso un backplane e quel backplane diventa... Quindi, è lì che colleghi una cache distribuita. Non ho intenzione di andare oltre i dettagli di quello specifico. Esaminerò i primi due ma non il terzo.

Ora, la cosa specifica su ASP.NET core la memorizzazione nella cache specifica è che i dati esistono solo nella cache. Questo è quello che stavo dicendo non inserirlo nel database. Non c'è bisogno. Questi sono dati temporanei. Ne hai bisogno solo per 20 minuti, 30 minuti, un'ora, 2 ore, qualunque cosa dopo che i dati debbano andare via. Quindi, se è temporaneo, dovrebbe esistere solo nella cache e quando i dati esistono solo nella cache ed è una cache in memoria, cosa potrebbe andare storto? Potresti perdere dati perché sono tutti in memoria. La memoria è volatile. Quindi, una buona cache distribuita deve gestire quella situazione, ovviamente, ciò significa che devi replicare.

Messaggistica Pub/Sub ed Eventi

Il terzo caso d'uso è che molte applicazioni devono eseguire operazioni di tipo flusso di lavoro. Microservice ne è un ottimo esempio. Hanno bisogno di coordinare le attività, anche se i microservizi non sono l'argomento ma anche ASP.NET core le applicazioni occasionalmente devono farlo. Così, messaggistica pub/sub è un altro modo perché, ancora una volta, tieni presente che hai un'infrastruttura in atto in cui tutte queste scatole sono collegate a questa infrastruttura in memoria ridondante. Quindi, perché non usarlo anche per la messaggistica pub/sub?

Quindi, questi sono i tre casi d'uso comuni. Quindi, questi sono i tre modi che dovresti usare NCache o una cache distribuita se vuoi trarne vantaggio, se vuoi massimizzare il vantaggio.

Demo pratica

Quindi, prima di entrare nel modo in cui li usi effettivamente, voglio mostrarti come appare una cache distribuita. Userò Azure come ambiente e userò NCache. Ed è solo una rapida demo di...

Configurazione di un ambiente

Quindi, ho effettuato l'accesso ad Azure. Ho quattro macchine virtuali, ancora una volta queste sono tutte .NET core.

Quindi, ho quattro macchine virtuali in Azure. Due di questi li userò come VM del mio server cache, il che è fondamentalmente: questi sono quei due... Avrò un client Windows e un client Linux. Quindi, se hai perché .NET core supporta Linux. Se hai .NET core come l'applicazione che potresti voler distribuire su Linux. Ora, in caso di NCache, ancora una volta, non mi occupo di marketing NCache. Ma in caso di NCacheè similare a quella del .NET core quindi può essere eseguito su Windows o Linux, sia sui server che sui client.

Bene! Entriamo in... Quindi, ho effettuato l'accesso a questo client, la casella del client di Windows. Quindi, ora vado avanti e creo una cache per me stesso.

Crea una cache raggruppata

Quindi, userò questo strumento chiamato NCache, le NCache direttore in realtà non viene fornito con l'open source. C'è un equivalente da riga di comando, ma qui sono solo pigro. Quindi, userò solo NCache manager ma è la stessa funzionalità. La funzionalità non cambia, quindi ho appena avviato NCache gestore. Dirò di creare una nuova cache. Hai appena nominato una cache. Tutte le cache sono nominate. Pensala come una stringa di connessione al database, quindi scegli una topologia. Non entrerò nelle topologie, ma verso la fine parlerò di ciò che una cache deve fare per essere in grado di gestire tutte queste esigenze. Quindi, userò solo la topologia della cache della replica della partizione. Replica asincrona. Aggiungerò il mio primo server cache. 10.0.0.4 e il secondo 5. Quindi ho due server cache. Manterrò tutto come predefinito. Vado agli sfratti e a tutti gli altri.

E ora specificherò due client. 10.0.0.6 e 7. Verrò qui e avvierò semplicemente la cache. Quindi, pensalo proprio come un database, invece di un server hai più server che costituiscono il cluster e crei un cluster di server cache e quindi assegni i client. Non devi assegnare i client perché puoi semplicemente eseguirli, ma lo sto facendo qui perché ti dà un po' più di flessibilità.

Simula lo stress e monitora le statistiche della cache

Quindi, voglio andare a testare il client. Quindi, io sono il cliente. Penso di essere 10.0.0.6. fammi solo assicurarmi quale sono io. Penso di essere 10.0.0.6 penso. Dai! Quindi, ancora una volta, sto facendo tutto all'interno della rete virtuale di Azure, quindi il client è effettivamente il server delle applicazioni e la cache è ora insieme. In caso di NCache avresti potuto ottenerlo dal azure marketplace. Quindi, .6 è il client Windows. Quindi, avvierò PowerShell e mi assicurerò di poter vedere. Bene! Bene! Quindi, vedrai che questo client parlerà con la cache e ora sto facendo circa cinque seicento richieste al secondo in ciascuno dei server della cache. Mi permetta di aggiungere un po' più di carico. Apro un altro PowerShell e sottolineerò un'altra istanza del client. Ora vedrai che salirà da circa mille a milletrecento per server.

e ora facciamo... In realtà... Quindi, ho aperto un prompt dei comandi qui. Fammi accedere alla casella di Linux. Ops! E scusa! Iniziamo PowerShell lì. Devo importare le librerie parziali del clone di NCache e farò la stessa cache demo stressante, quindi farò... Prima di farlo, come puoi vedere, sto facendo da tredici a millecinquecento per server, aggiungilo come client basato su Linux che parla alla cache e ora all'improvviso ho quasi duemilacinquecento richieste per server.

Quindi, sto facendo circa cinquemila richieste al secondo su due server. Come ho detto, puoi aggiungere sempre più carico e man mano che esaurisci quelle due caselle che farai, ne aggiungi una terza, quindi ne aggiungi una quarta. Quindi, è così semplice e ancora una volta questa è una simulazione. È una cosa reale come uno strumento di stress test. Quindi, questo è ciò che devi tenere a mente. Ora continuerò con la cache effettiva. È un programma di stress test. Si inserisce come un array di byte. Penso che metta 1k di dati. Aggiunge, aggiorna, ottiene. Quindi, simula qualunque sia la tua applicazione effettiva e ha parametri che puoi modificare per vedere qual è il rapporto tra lettura e scrittura di cui stavamo parlando. E questo è uno strumento con cui diamo NCache, in modo da poterlo effettivamente testare nel tuo ambiente. Quindi, per vedere come NCache sta effettivamente funzionando prima di dedicare molto tempo alla migrazione dell'applicazione su di essa. Fammi passare velocemente. Penso di gestirlo.

ASP.NET Core Archiviazione della sessione

Quindi, ora che abbiamo visto come appare una cache, come puoi aggiungere più client e come puoi aggiungere più carico su di essa, è molto semplice. Quindi, il modo più semplice per utilizzare una cache è inserirvi sessioni. E per le sessioni ci sono due cose che puoi fare.

O puoi semplicemente usare un provider IDistributedCache. Diciamo NCache Ha uno. Non appena lo specifichi NCache come IDistributeCache, ASP.NET core inizia a usarlo per la memorizzazione delle sessioni. E lascia che te ne mostri davvero un po'. Ho questo ASP.NET core applicazione. Come puoi vedere qui. Nei miei servizi di configurazione, sto specificando This, sto dicendo make NCache il mio provider di cache distribuita. Quindi, non appena lo faccio, inizia e poi sto usando sessioni standard e queste sessioni standard useranno IDistributedCache che ora sta usando NCache. Quindi, qualunque sia il provider di cache distribuita che hai, è tutto ciò che devi fare. Come puoi vedere, il codice cambia molto piccolo e l'intera applicazione viene automaticamente, tutte le sessioni verranno immediatamente messe in una cache distribuita.

public IConfigurationRoot Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
	// Add framework services.
	services.AddMvc();
	//Add NCache as your IDistributedCache so Sessions can use it for their storage
	services.AddNCacheDistributedCache(Configuration.GetSection("NCacheSettings"));
	
	//Add regular ASP.NET Core sessions
	services.AddSession();	
}

E, una delle cose che abbiamo visto è quando molti dei nostri clienti, quando archiviano sessioni nel database e hanno problemi, si collegano a qualcosa come NCache è istantaneo e il beneficio che vedono, il notevole miglioramento è istantaneo. Il minimo sforzo e il massimo guadagno c'è. Perché, ovviamente, c'è anche la memorizzazione nella cache diretta dell'applicazione.

Ne salterò alcuni perché penso... Quindi, ci sono diversi modi per specificare le sessioni. Uno era IDistributedCache, il secondo è che puoi effettivamente utilizzare un provider di sessione personalizzato che NCache ha anche e di nuovo tutti questi sono open source. Quindi per la memorizzazione nella cache delle risposte, di nuovo, fai la stessa cosa. Tu specifichi NCache come cache distribuita e diventa automaticamente la cache per la cache di risposta. Non entrerò più nel dettaglio.

ASP.NET Core Memorizzazione nella cache dei dati dell'app

Voglio che tocchi un po' di più questo argomento. Quindi, quando esegui la memorizzazione nella cache dei dati dell'applicazione, a differenza delle sessioni, devi ora eseguire la programmazione API. A meno che tu non stia eseguendo il core del framework di entità.

Quindi, ad esempio, in caso di NCache, sempre open source, c'è un provider principale EF. Quindi, abbiamo implementato metodi di estensione per EF core. Quindi, puoi effettivamente collegarti NCache open source e usa le tue normali query core EF e alla fine puoi dire dalla cache o dal database, qualcosa, è solo un metodo di estensione che inizia automaticamente a memorizzare nella cache le cose. Ti dà il controllo totale su ciò che vuoi memorizzare nella cache, ciò che non vuoi memorizzare nella cache. Dai un'occhiata. È un modo davvero potente.

Se stai facendo EF core, che è quello che ti consiglio di fare. Penso, per qualsiasi ASP.NET core applicazione, tutta la programmazione del database dovrebbe essere eseguita tramite il core EF, soprattutto perché il core EF è un'architettura molto più gradevole rispetto al vecchio EF. Quindi, questo è un modo per farlo.

L'altro è che puoi effettivamente realizzarli. Puoi utilizzare l'API IDistributedCache o l'interfaccia che ti offre la flessibilità di non essere bloccato in un'unica soluzione di memorizzazione nella cache, ma ha un costo. È molto semplice. C'è solo un input per ottenere e questo è fondamentalmente, beh, c'è anche una rimozione. Questo è tutto. E, tutte le cose di cui abbiamo parlato, se non riesci a mantenere la cache sincronizzata con il database, tutte quelle cose le perdi. Quindi, se vuoi beneficiare di tutte queste funzionalità, devi accedere all'API che in realtà le supporta tutte. E ancora, poiché ti impegnerai in una cache open source, di solito è più facile farlo, ma la memorizzazione nella cache diretta dell'applicazione, l'API è molto semplice, c'è una chiave e c'è un valore. Il valore è il tuo oggetto.

Mantenere la cache fresca

Ora, lasciami venire a quell'argomento su cosa ti consente di mantenere la cache fresca. Le informazioni davvero preziose, giusto? Cosa fai?

Bene, la prima cosa che fanno quasi tutte le cache distribuite, le scadenze! Tu fai l'espressione assoluta. Qualunque cosa tu metta nella cache, dici di rimuoverla dalla cache tra cinque minuti. Quindi, è sicuro tenerlo in cinque minuti, penso che in cinque minuti sarò l'unico ad aggiornarlo dopo che altre persone potrebbero farlo. Così, NCache ce l'hanno, ce l'hanno anche tutti gli altri. Transitorio... c'è un'espressione scorrevole per dati transitori come sessioni e altri che dopo aver finito di usarla, se non viene toccata per un certo periodo di tempo, diciamo sessioni, quando l'utente si disconnette dopo 20 minuti di inattività, la sessione scade. Quindi, succede la stessa cosa. Le scadenze, praticamente tutte le hanno.

La prossima è la cache sincronizzata con il database. Questa è una funzionalità che ti consente di fare in modo che la cache monitori il tuo database. Quindi, puoi effettivamente... quando aggiungi cose a NCache, diciamo, puoi avere una dipendenza SQL che lo consente NCache monitorare. La dipendenza SQL è una funzionalità ADO.NET del server SQL che utilizziamo. La dipendenza SQL consente di specificare l'istruzione SQL o la procedura di archivio che consente NCache per monitorare il database del server SQL, quel set di dati specifico. E, se si verificano modifiche in quel set di dati, il server SQL lo notifica NCache e qualsiasi cache rimuove quei dati dalla cache o se combini quella sincronizzazione con una funzione di lettura, la ricarica. Quindi, supponiamo che tu abbia un oggetto cliente che è stato memorizzato nella cache ed era una dipendenza SQL e che il cliente è stato modificato nel database che sono i dati transazionali dei clienti, quindi cambierà frequentemente. È possibile utilizzare il read-through e ricaricare automaticamente su entrambe le espressioni o sincronizzazione del database.

Quindi ora, improvvisamente la tua cache è responsabile del monitoraggio dei dati. Esistono tre modi per farlo, c'è la dipendenza SQL, la dipendenza DB e il sigillo sono procedure archiviate CLR. Non entrerò nei dettagli. Puoi andare sul nostro sito web e leggerlo. Ma ancora una volta, la cosa più importante è che se non hai la sincronizzazione della cache con il database come funzionalità, sei limitato a quei dati statici e di sola lettura. E poi ciò limita il tutto e di nuovo puoi sincronizzare questa cache anche con l'origine dati non relazionale.

E la terza cosa è che potresti avere una relazione... il più delle volte memorizzerai nella cache dati relazionali, che hanno relazioni uno-a-molti uno-a-uno. Quindi, diciamo, un cliente ha più ordini. Se rimuovi il cliente, anche gli ordini non dovrebbero rimanere nella cache perché forse lo hai eliminato dal database. Quindi, se non lo fai, la tua applicazione deve fare tutto questo, ma c'è un oggetto cache ASP.NET che ha questa funzione chiamata funzione di dipendenza dalla chiave. NCache lo ha implementato che ti consente di avere una relazione uno-a-molti o uno-a-uno tra più elementi della cache e che se una cosa viene aggiornata o rimossa, l'altra viene automaticamente rimossa. Quindi, queste quattro cose combinate ti consentono di assicurarti che la tua cache rimanga aggiornata e coerente con il database. E questo è ciò che ti consente di iniziare a memorizzare nella cache i dati. Quindi, questo è il primo vantaggio.

Read-thru e Write-thru

Il secondo è che se puoi usare read-through e write-through, semplifica la tua applicazione.

Read-through, come ho detto, puoi combinare il read-through per il ricaricamento automatico, cosa che la tua applicazione non sarebbe in grado di fare se non avessi il read-through. E, di nuovo in scrittura, puoi aggiornare la cache e la cache può aggiornare il database soprattutto se hai un diritto dietro, di nuovo stiamo parlando di prestazioni, giusto? Quindi, tutti gli aggiornamenti devono essere apportati al database. Bene, e gli aggiornamenti saranno lenti rispetto alle letture dalla cache. Quindi, se potessi delegare gli aggiornamenti alla cache e dire che aggiornerò la cache, perché non vai ad aggiornare il database per me. So che è sicuro perché e lavoreremo sull'eventuale modello di coerenza che è ciò su cui si basano i sistemi distribuiti che sacrifichi o diventi più indulgente sulla coerenza e vai con l'eventuale modello di coerenza. Il che significa che anche se in questo momento non è coerente, poiché la cache è aggiornata, il database non lo è, entro pochi millisecondi verrà aggiornato. E alcuni dati non puoi permetterti di farlo, ma molti dati puoi.

Quindi, facendo subito dietro, improvvisamente anche i tuoi aggiornamenti sono super veloci, la tua applicazione non deve sostenere il costo dell'aggiornamento del database. La cache lo fa perché è una cache distribuita e può assorbirla come batch e ce ne sono altre. Quindi, una volta che inizi a farlo, significa che ora puoi memorizzare nella cache molti dati.

Raggruppamento di dati

Una volta memorizzati nella cache i dati, sempre più dati, la cache diventa ricca quasi come un database, il che significa che stai memorizzando nella cache quasi tutti i dati.

Quando si memorizzano nella cache quasi tutti i dati, il valore della chiave non è sufficiente per trovare le cose. Devi essere in grado di cercare le cose. AppFabric usato per avere gruppi e sottogruppi, tag chiamati tag, a proposito, NCache open source ha AppFabric involucro. Quindi, quelli di voi che hanno ottenuto AppFabric può trasferirsi NCache come cosa gratuita. Quindi, il raggruppamento ti consente di recuperare facilmente i dati.

Trovare i dati

La ricerca SQL ti consente di trovare cose come, dammi tutti i miei clienti dove la città è New York. Quindi, ora stai facendo il tipo di database di query nella cache. Come mai? Perché la tua cache non contiene molti dati.

L'intero paradigma sta cambiando perché stai andando con sempre più memoria. Anche in questo caso, il database è il master. Quindi, la cache lo ha ancora solo per un periodo di tempo temporaneo.