Infrastruttura Web
Fornire scalabilità per le applicazioni ASP.NET
Iqbal Khan
In un riepilogo delle:
- Scalabilità colli di bottiglia nelle applicazioni ASP.NET
- Le opzioni di archiviazione dello stato sessione
- Topologie di memorizzazione nella cache disponibili
- Cache distribuita necessarie funzionalità
Contenuto
Dove sono i problemi
Perché esistono I problemi
Qual è la risposta?
La memorizzazione nella cache topologie
Scelte diverse
World REAL
La popolarità di ASP.NET, il framework di applicazione Web da Microsoft, continua a crescere leaps e i limiti all'interno per gli sviluppatori, organizzazione e rango IT. Vi è un'area di difficoltà, tuttavia: scala le applicazioni ASP.NET all'esterno della casella semplicemente non è possibile.
Scalabilità ha due significati in questo contesto. In primo luogo, è necessario essere in grado di efficace gestire carichi di utenti massimo poiché ogni applicazione passa attraverso picchi e valleys in termini di numero di utenti connessi in qualsiasi punto nel tempo. Quando si progetta l'infrastruttura, che si desidera progettare l'applicazione in modo è possibile gestire i carichi di picco come carichi in modo efficiente e di velocità come nonpeak.
In secondo luogo, è necessario essere in grado di aumentare la capacità totale del sistema. Oggi è necessario solo 5.000 utenti. Sei mesi, un anno a strada, potrebbe avere 10.000 15,000 o 20.000 e in pochi anni è Impossibile terminare le con 100.000 utenti. La possibilità di aumentare il numero di utenti senza grinding all'applicazione di un arresto è quale scalabilità tutti su. Non è possibile aggiungere più utenti senza influire negativamente riduce le prestazioni in modo evidente o, se è presente qualsiasi riduzione, dovrebbe essere in un intervallo accettabile.
Una tipica applicazione ASP.NET viene distribuita su uno o più server Web che sono collegati tra loro in una Web farm, con un bilanciamento del carico che distribuisce il traffico ai tutti i server Web. In teoria, il server Web più si aggiungono, più richieste sarà in grado di elaborare al secondo. L'architettura di una Web farm è necessario fornire scalabilità a ASP.NET. Ecco la teoria; la realtà è leggermente diverso.
Il problema per le applicazioni ASP.NET è che mentre tecnologia Web fornisce un'architettura di Web farm e sistemi di bilanciamento del carico elegante, le tecnologie di archiviazione dei dati sono non mantenuto fino. Certamente è possibile scalare in un'applicazione Web aggiungendo ulteriori server oppure aumentando il livello di singolo server con memoria e potenza di CPU.
Ma che come, l'archiviazione dei dati non è in grado di modificare le proporzioni nelle stesse proporzioni. Vengono ridimensionati, ma non quanto il livello di applicazione Web. Di conseguenza, qualsiasi elemento nell'applicazione ASP.NET archiviazione dei dati o di accesso ai dati è un potenziale collo di bottiglia di scalabilità. Al punto più un server di database non viene ridimensionati per dati di sessioni o le applicazioni.
Dove sono i problemi
Si esaminiamo le azioni accesso o archiviazione diverse che si verificano in un'applicazione ASP.NET, a partire da archivio di sessione. Per ogni richiesta di utente, una sessione viene letta dall'archivio all'inizio e scritte in archivio alla fine della risposta. All'inizio della richiesta utente, la pagina contiene eseguire e per tale, richiede i dati della sessione. I dati intera sessione, chiamati un "oggetto di sessione", vengono caricati in modo che pagina, mentre viene eseguita, può fare riferimento i dati. La pagina verrà leggere alcune di tali dati dall'oggetto sessione. Verrà inserire alcuni ulteriori dati nell'oggetto sessione. Tutto questo errore di verifica all'interno del processo ASP.NET e non trip di archiviazione di sessione vengono apportate.
Quando viene eseguita la pagina in esecuzione, alcune risultato deve essere inviato nuovamente all'utente. La sessione probabilmente viene aggiornata durante questo periodo di tempo in modo che ora sessione deve essere salvato nell'archiviazione. Esso verrà conservato stored fino alla successiva richiesta utente per la stessa sessione e lo stesso processo viene ripetuto stesso.
Dal punto di vista un utente, si fa clic su un collegamento, quando che l'utente vedrà la pagina risultante dalla tale collegamento, lettura una sessione e una sessione è stato scritto nuovamente all'archivio una volta. Pertanto esistono due trip in un archivio di sessione ha effettuato l'applicazione ASP.NET.
Ora è possibile eseguire le operazioni matematiche. Se è stato ottenuto 10.000 utenti tutte le pagine di accesso allo stesso tempo, sarà forse 1.000 richieste al secondo. Ogni utente sarà essere scegliendo qualcosa ogni pochi secondi, pertanto ogni secondo che sarà necessario almeno 1.000 e probabilmente più le richieste da Web farm.
Si supponga di 1.000 o più richieste intende Web farm e ogni richiesta dai risultati di server Web in due trip all'archivio di sessione. Dal punto di vista del Web, ciò significa 2.000 trip all'archivio di sessione. È possibile visualizzare la velocità con cui il carico può aumentare. Si tratta di un'unica posizione che può verificarsi un collo di bottiglia a livello di scalabilità.
I colli di bottiglia scalabilità può verificarsi anche mentre una pagina è in esecuzione e necessarie per leggere o scrivere alcuni dati dell'applicazione. Come esempio viene utilizzato il volo aereo disponibilità. L'utente fa clic su una pagina per cercare i voli da una posizione a altra, che possono risultato più trips lettura al database dell'applicazione. Quindi, ovviamente, l'utente desidera effettuare un impegno aereo, che richiede alcuni dati da inserire nel database. Questo dato viene detto i dati dell'applicazione e viene memorizzato nel database; questa operazione di salvataggio potrebbe rendere più trip di database per memorizzare più elementi di dati.
Pertanto, è possibile, alla fine risultato fino con il numero di trip al database da 5, 10, 15 o 20 volte più il numero effettivo di richieste degli utenti. Pertanto stress nel database è che più e può essere un collo di bottiglia principale.
Un collo di bottiglia di scalabilità terza viene fornito su se si utilizza un ambiente SOA (Architettura orientata ai servizi) e l'applicazione esegue chiamate a un altro layer di servizio, che può essere all'interno del centro dati o in un centro dati diversi.
L'architettura del livello di server in genere prevede una server farm e quindi è scalabile nello stesso modo architettura dell'applicazione Web è. Ma il livello di servizio ha la stessa colli di bottiglia scalabilità per l'applicazione poiché dipende da un proprio database.
L'applicazione ha pertanto dipendenze altri servizi, con dipendenze sui database, a sua volta sono colli di bottiglia di scalabilità e la catena è solo come sicuro come relativo collegamento weakest. Se un servizio non viene ridimensionati causa del relativo database, l'applicazione non è adattata (vedere la Figura 1 ).
Nella figura 1 il database diventa un collo di bottiglia a livello di Web farm si espande.
Non importa veramente se il database è un mainframe o un database relazionale. L'accesso ai dati o l'archiviazione dei dati semplicemente non è possibile modificare le proporzioni, e non può mantenere ritmo con la scalabilità della tecnologia Web. E questi colli di bottiglia nell'archivio dati impedire le applicazioni ASP.NET di ridimensionamento.
Perché esistono I problemi
Perché non scala archiviazione dei dati Affrontiamo innanzitutto le tre opzioni di archiviazione dello stato sessione in Microsoft sono disponibili: InProc, StateServer e SqlServer. InProc presenta limitazioni. È stato progettato per essere utilizzato in un ambiente a server singolo, processo e non funziona in un ambiente di ASP.NET multiserver o multiprocesso. La sessione non viene mantenuta.
Ecco cosa succede. L'utente avvia su un server e la sessione viene creata esiste. Se il sistema di bilanciamento del carico invia quindi l'utente a un server diverso, l'applicazione non disponibili tale sessione, verrà ritiene che l'utente sta avvio aggiornata e chiedere all'utente per accedere nuovamente. Ogni volta che un utente fa clic su qualsiasi elemento, dovrà accedere, pertanto utente non saranno in grado di continuare. L'applicazione non funzionerà.
Un modo è possibile risolvere è utilizzando la funzionalità "Sticky Notes sessioni", che consente sempre route la richiesta dell'utente eseguire allo stesso server in modo dall'applicazione troverà tale sessione sul server.
È inoltre possibile gestire limitazioni InProc non creando un Web garden sul server. Un Web garden è quando l'applicazione dispone di più processi di lavoro ASP.NET in esecuzione sullo stesso server. Se si evita di utilizzare un Web garden, c'è solo un processo e che almeno consente InProc essere utilizzata in una Web farm.
Queste due soluzioni alternative lontana da ideale, tuttavia sono. Sessioni di Sticky Notes possono causare un collo di bottiglia scalabilità principale poiché il carico sui alcuni server aumenta più ad altri utenti perché la lunghezza di una sessione utente non è uniforme. Alcuni utenti accedere per solo minuto, altri utenti per 20 minuti. Alcuni server riceveranno numerose sessioni, ma quelli verrà essere praticamente di vuoto o libero o inattivo. Anche se si aggiungono più caselle, si è non necessariamente migliorare la velocità effettiva.
Inoltre, InProc presenta limitazioni di memoria. Ogni sessione del processo ASP.NET richiede memoria. Come si aumenta il numero di sessioni, aumentare notevolmente i requisiti di memoria del processo di lavoro. In una piattaforma a 32 bit, è tuttavia, vi è un limite di 1 GB di memoria per un processo di lavoro e che rappresenta un problema. È impossibile aumentare dati della sessione oltre a ciò che si adatta in una memoria di un gigabyte lavoro processo, insieme con altro codice dati e dell'applicazione. Pertanto InProc determina i colli di bottiglia. E più utenti avere, si verificheranno più questi problemi.
StateServer memorizza lo stato sessione in un processo è distinto dal processo di lavoro ASP.NET, ma presenta troppo limitazioni. È possibile configurarlo in modo che tutti i server Web è incluso il proprio StateServer oppure è possibile dedicare una finestra separata e mantenere lo stato completamente in tale casella.
Con l'opzione prima è il problema che è comunque necessario utilizzare le sessioni di Sticky Notes. Ogni volta che la sessione è stata creata, ecco dove avere sempre tornare a esso. Questa opzione prima attenua solo il limite di giardino InProc Web. Esso non risolvere il problema sessioni Sticky Notes che è possibile mantenere con le caselle aggiuntive che non utilizzate anche quando altri utenti sono ostruiti. Il risultato finale per l'utente è che il suo tempo sessione e la risposta diventa estremamente lenta.
L'altro svantaggio di questa opzione di configurazione è che se qualsiasi server Web, il StateServer su che casella server Web anche interrotta, pertanto si perde tutte le sessioni. Ha valore True perdere tutte le sessioni in un sito Web ma in caso di perdita tutte le sessioni archiviate in tale casella e che non accettabile. In teoria, non si desidera perdere tutte le sessioni.
Se si sceglie la configurazione di altre offerte StateServer, una casella StateServer dedicata, è non è più necessario utilizzare una sessione di Sticky Notes poiché ogni server Web viene inviata alla casella stessa dedicata. Ma ora si dispone di un problema più grande: se tale casella mai interrotta, intera Web farm si è premuto perché ogni server Web tentando di ottenere la sessione da tale casella.
Non Ecco tutte. Questa casella StateServer dedicata Ottiene sovraccaricata vengono aggiunti più server Web e un'escalation di transazioni al secondo. Di conseguenza, rapidamente diventa un collo di bottiglia a livello di scalabilità. Pertanto, il problema di scalabilità non è risolti con StateServer, non con una configurazione.
Ora per SqlServer, che archivia lo stato sessione in un database di SQL Server e può essere considerati come un StateServer dedicato. Si tratta di Microsoft server di database più importante progettato per ambienti di transazione elevato. È più scalabile rispetto un StateServer perché è possibile creare un cluster di server di database.
In configurazione SqlServer, tutti i server Web connettono effettivamente a una casella SqlServer dedicata in cui sono memorizzate tutte le sessioni. È come se ognuno dei server Web sono stati collegata a una casella di StateServer dedicata. Il concetto dietro questa è che SqlServer sarà più scalabile rispetto un StateServer. Ma SqlServer non è veloce come un server di stato, poiché un StateServer è un archivio dati in memoria e di conseguenza, ha prestazioni accettabili. SqlServer d'altra parte, non è un archivio dati in memoria. È un archivio di dati basata su disco. Tutti i database vengono mantenuti sul disco perché sono aumento delle dimensioni così grandi che la memoria non è sufficiente tenere dell'intero database. In un database di conseguenza, i dati vengono archiviati in archiviazione persistente, che è un disco di. A causa di spazio su disco, SqlServer prestazioni non sono veloce, determinando a discesa delle prestazioni.
SqlServer può entrare più configurazioni. È in una configurazione autonoma, cioè i più comuni, presente solo un server di database che comunicare con tutti i server Web e si aumentare le dimensioni del Web farm e si aggiungono più server Web, è possibile inserire più carico sul database (vedere la Figura 2 ).
Nella figura 2 sessioni ASP.NET ancora un collo di bottiglia e un database anche non fullyscalable
Inoltre, si hanno un problema di prestazioni perché SqlServer non è basato sulla quantità di memoria e si dispone di un problema di scalabilità perché non è in grado di scalare più. È possibile scalare rendendo più potente l'hardware aggiungendo CPU alla casella di, ma è impossibile continuare ad aggiungere più caselle di server di database come aumentare Web farm. È possibile può passare da uno a due o tre due server in modo che SqlServer fornisce un database clustering funzionalità, che vengono ridimensionati da più di un StateServer ma dispone anche di limitazioni.
L'altri problema SqlServer dispone di archiviazione è che tutte le sessioni vengono mantenute in un'unica tabella. I conflitti di blocco per l'accesso simultaneo e aggiornamenti simultanei dei dati sessione diventa evidenti quando scalare. Con più transazioni al secondo, è più ritardi di blocco poiché tutto ciò che viene mantenuto in una tabella.
Pertanto, sebbene SqlServer scale più server di stato, è mani di un problema di prestazioni e scalabilità non sufficientemente. Inoltre, non viene ridimensionati in modo lineare. Che si suppone per poter aumentare di una Web farm da un 5-50-100 server farm e Web farm stessa dovrebbe aumento delle dimensioni abbastanza facilmente; tuttavia, l'accesso ai dati non aumentare Analogamente. Come È indicato in precedenza, un database è uno di questi accessi di archiviazione dei dati non aumentare, pertanto la memorizzazione di sessioni in un database non qualsiasi miglioramento principale. È solo un miglioramento incrementale in un ambiente server di stato. Inoltre, un SqlServer diventa un collo di bottiglia per dati dell'applicazione nonché per i dati delle sessioni. Di conseguenza, un server di database non viene ridimensionati per dati di sessioni o le applicazioni.
Qual è la risposta?
La soluzione è un meccanismo di archiviazione in memoria, può essere estremamente veloce e veloce un StateServer. Tuttavia, dovrebbe essere quasi lineare scalabile. Una scalabilità lineare significa che quando si aggiungono più server, quasi sono moltiplicando la capacità. Ad esempio, se è possibile gestire le transazioni 10.000 al secondo con una casella, aggiungendo una seconda casella deve assegnare è vicino al transazioni 20.000 al secondo totale. Si noti che "quasi lineare" non significa esattamente 20.000, potrebbe essere 19,000, perché non, tuttavia, essere 12,000 o 15,000. E questo è ciò che occorre: archiviazione che può crescere in modo quasi lineare e inoltre deve essere in memoria.
A causa di queste due esigenze, è non parla archivio permanente, che prevede altri requisiti ed è destinato a lungo termine. Un database è destinato all'archiviazione a lungo termine, mentre in memoria archiviazione è sempre temporaneo e temporanei. Ma nostre esigenze sono temporanei. È solo necessario memorizzare i dati in questo archivio temporaneo durante una sessione utente o forse per la durata di un'applicazione, alcune ore a pochi giorni o forse alcune settimane in più. Quindi i dati possono passare immediatamente poiché è sempre memoria master permanente, ovvero il database in cui è possibile caricare i dati dal nuovo.
Pertanto, tutto questo presente, è possibile considerare un meccanismo di archiviazione denominato una "distribuita cache," un concetto è diventato comune perché offre i vantaggi citati in precedenza, come Nella figura 3 viene visualizzato.
Nella figura 3 cache distribuito alleggerendo pressione sul server di database
Una cache distribuita è in memoria, in modo che è veloce ed è progettato per distribuire crescita molto lineare, soprattutto se è necessario il meccanismo di distribuzione a destra (detto anche memorizzazione nella cache topologia).
Una cache distribuita deve fornire ad alte prestazioni e scalabilità lineare e perché è presente in memoria, in modo che, se una macchina interrotta deve fornire replica della memoria in tale computer diventa disponibile, un altro computer avranno i dati e si non perde qualsiasi. Replica fornisce più copie degli stessi dati in posizioni diverse in finestre diverse e da operazioni, è possibile ottenere 100 % volta per tutta la durata dell'archiviazione dei dati.
Una cache distribuita archivia un oggetto .NET o di un oggetto Java o, per cui è rilevante, tutti gli altri dati come un documento XML. Memorizza i dati in un formato preparato. Non è necessario il concetto di tabelle e le righe e le chiavi primarie e chiavi esterne che dispone di un database. Per i programmatori, una cache distribuita è essenzialmente una HASH tabella in cui vi è una chiave e ogni chiave ha un valore e che valore è un oggetto. È necessario conoscere la chiave e basato sulla chiave, è possibile recuperare l'oggetto desiderato. Questa è una cache logica che può estendersi su più server. È possibile aggiungere server allo stesso tempo a crescere dimensione cache del cluster e allo stesso tempo per ridurre il cluster cache senza alcuna interruzione è possibile rimuovere le caselle.
La memorizzazione nella cache topologie
Vengono replicate le varie topologie deve fornire una cache efficacia partizionata, un ibrido di replicata e partizionate e un client o cache locale. L'idea è per topologie di memorizzazione nella cache diverse per i diversi tipi di utilizzo, rendendo la cache estremamente flessibili. Una topologia replicata replica la cache molte volte, a seconda come numero di volte necessario (vedere la Figura 4 ). Situazioni in cui è possibile siano un utilizzo della cache che utilizzano un'elevata quantità di lettura, ma non molto aggiornamenti è destinato.
Nella figura 4 la cache replicata è ideale per l'utilizzo di un uso intensivo di lettura
Una cache partizionata è la topologia altamente scalabile per i dati che utilizzano un'elevata quantità di aggiornamento o transazionale che deve essere memorizzato nella cache. Potrebbe trattarsi di dati di sessione ASP.NET, ovvero molto transazionale. Come accennato in precedenza, per ogni richiesta Web, la sessione viene letta una sola volta e aggiornata una sola volta, ha un numero uguale di letture e scritture.
Una topologia partizionata (vedere la Figura 5 ) è ideale per gli ambienti in cui gli aggiornamenti devono essere eseguiti almeno più volte mentre si stanno eseguendo operazioni di lettura o piuttosto simile a quella. In questa topologia, la cache viene diviso. Quando si aggiungono i server di cache di più e più, la cache è ulteriormente partizionati in modo che Nth quasi uno (N indica il numero di nodi) della cache è archiviato in ogni server di cache.
Nella figura 5 di cache partizionata è ideale per l'utilizzo di un uso intensivo di scrittura.
Una terza topologia è un ibrido delle versioni partizionate e replicate. È possibile eseguire la partizione la cache e, allo stesso tempo, è possibile replicare ogni partizione. Di conseguenza, è possibile ottenere il meglio di entrambi i mondi. Sarà possibile per partizione e aumentare le dimensioni, più è possibile replicare per la disponibilità per assicurarsi che i dati non siano persi (vedere la Figura 6 ).
Nella figura 6 cache replica partizione sono ideali per intensiveusage scrittura con affidabilità.
Con l'aiuto del topologie ibrido partizionata e replica partizionata, si può aumentare la cache in modo lineare in termini di scalabilità.
Un client o la cache locale è la quarta estremamente utile che si trova sul server dell'applicazione. Il tipo della cache è molto simile all'applicazione e può essere persino InProc. È in genere un piccolo sottoinsieme della cache distribuita grande effettivo e si basa qualsiasi è stata richiesta l'applicazione in quel momento. Tutte le richieste di applicazione, viene conservata una copia nella cache client. La volta successiva che richiesti dall'applicazione gli stessi dati, automaticamente troveranno nella cache client. Non è necessario passare alla cache distribuita, per salvare anche questo come un viaggio, poiché la cache distribuita è spesso attraverso la rete su un server cache separato o di un cluster di server di cache. Una cache client consente un incremento di prestazioni e scalabilità aggiuntiva.
I dati in una cache client da mantenere sincronizzati con la cache distribuita. Se viene modificati i dati stessi nella cache distribuita, la cache distribuita deve sincronizzare le modifiche con la cache del client. Questo è un aspetto importante, non si desidera disporre di sufficiente una cache locale viene completamente disconnessa. Questo è solo l'equivalente di una cache di InProc, non è accettabile poiché è necessario problemi di integrità dei dati. È possibile disporre più copie dei dati stessi che Ottiene sincronizzati.
Scelte diverse
Sono disponibili più funzionalità di memorizzazione nella cache distribuita in corso... E, come nella maggior parte dei casi, soluzioni liberi forniscono un insieme di funzionalità più limitato mentre quelli esterna offrono molte più opzioni e funzionalità.
A parte da ad alte prestazioni, scalabilità e disponibilità elevata, una cache distribuita efficiente deve includere diverse funzionalità chiave che consentono di mantenere la cache aggiornata e sincronizzato con l'origine dati principale, se database o mainframe. La cache deve avere un'opzione di scadenza in modo da poter distinguere per eseguire la scadenza automatica, che può essere un'ora assoluta o cosa chiamato "scorrevole time". In sostanza, tempo di inattività, se non utilizza i dati, automaticamente è scaduto.
Una cache sarà inoltre in grado di gestire le relazioni tra diversi tipi di dati. La maggior parte dei dati sono relazionali. Ad esempio, se è stato ottenuto un cliente, sarà possibile gli ordini per tale cliente in modo da una relazione tra i dati dei clienti e i dati degli ordini. Se si memorizzare nella cache sia cliente e Ordine dei dati e si elimina accidentalmente i dati dei clienti dalla cache, è opportuno che l'ordine potrebbe essere eliminato automaticamente. In questo caso, non è noto se i dati dei clienti rimosso dalla cache o definitivamente eliminato. Nel caso si eliminato definitivamente, l'ordine è inoltre valida ora poiché l'ordine deve essere di un cliente valido.
Esistono altri tipi simili di relazioni che devono essere gestite nella cache. Se la cache non farlo, quindi l'applicazione deve tenere traccia e che è molto complesso. Un oggetto di cache di Microsoft in ASP.NET è molto utile viene definito un "cache dipendenza concetto." Un elemento memorizzato nella cache dipende da un altro. Se tale elemento nella cache è mai rimossi dalla cache o anche aggiornato, il primo elemento nella cache viene rimosso anche. Questo è un concetto di dipendenza di cache potente che dovrà essere disponibile in tutte le cache memorizzare nella cache i dati relazionali.
La sincronizzazione con il database è un'altra possibilità importante per la cache. In genere, un database è condiviso da più applicazioni. Se un'applicazione utilizza la cache è l'unico aggiornamento del database, probabilmente non è necessario la funzionalità di sincronizzazione del database. Ma abbastanza spesso, altre applicazioni, applicazioni talvolta terze parti, siano aggiornando dati nel database perché il database è un archivio condiviso, comune e le applicazioni non si utilizzano la cache. Le applicazioni .NET non potrebbero anche essere. Possono essere applicazioni di terze parti non controllano, ma verranno aggiornate nel database. Pertanto è necessario consentire situazioni in cui il database può essere aggiornato all'esterno dell'applicazione, ma alcuni dei dati che che sono stati aggiornati nel database viene memorizzata nella anche cache. Di conseguenza, la cache deve essere in grado di eseguire la sincronizzazione. Ha per poter sapere ogni volta che i dati che è non è più allo stesso modo in database. È necessario rimuovere i dati dalla cache e forse anche ricaricare la copia più recente dal database. Sincronizzazione del database può essere eseguita tramite gli eventi generati tramite il server di database o tramite la cache di polling del database. Gli eventi sono ovviamente più in tempo reale e polling è un leggero ritardo. Ma polling può risultare più efficiente se molti dati viene modificata.
Notifica dell'evento è una funzionalità più importanti che deve avere una cache distribuita efficacia. Una cache spesso è condivisa tra più applicazioni e anche all'interno di un'applicazione tra più utenti. Pertanto, la cache deve disporre di un meccanismo di notifica di evento nel caso, ad esempio, un oggetto memorizzato nella cache è aggiornato o rimosso. Se l'applicazione utilizza i dati stessi, sarà necessario ricevere una notifica in modo è possibile ricaricare sia dal database o una nuova copia dalla cache stessa. Un meccanismo di notifica consente di migliorare la collaborazione tra più utenti o più applicazioni tramite la cache.
World REAL
Gestione IT sia rivolta in tutti i problemi di prestazioni associati a database, e nel caso di colli di bottiglia, se si fortunato sufficiente consentire tali report per gli sviluppatori, potrebbe tentare risolverli. Sfortunatamente, lo sviluppo non sempre interno. Spesso vengono vivere con e gestione di un'applicazione di terze.
Il migliore in ogni caso, inserire per avviare l'implementazione di cache distribuita per aprire i colli di bottiglia e turbo-addebito delle applicazioni è con archivio di sessione di ASP.NET, poiché non è necessario variano in base agli sviluppatori. C'è nessuna programmazione coinvolti. Si tratta semplicemente di sostituzione di archivio di sessione esistente con una cache di distribuiti in memoria. Inoltre, l'implementazione di una cache distribuita per l'archiviazione sessione di ASP.NET consente per visualizzare i vantaggi di attribuzione per le prestazioni e scalabilità, e quindi è possibile decidere se eseguire la stessa operazione per i dati dell'applicazione.
Per sperimentare il miglioramento della scalabilità, si che sia necessario eseguire distribuito nella cache archiviazione in produzione oppure si dispone simulare tale carico nell'ambiente di prova. Si potrebbe avere accesso del controllo qualità consente di eseguire un test di stress in un ambiente di prova per simulare un carico elevato prima di passare una cache distribuita nell'ambiente di produzione. La maggior parte ai responsabili IT probabilmente non è grado di inserire una cache distribuita nella produzione a meno che non sono stato testato viene prima nel proprio ambiente QA anche se non Impossibile simulare la stessa quantità di carico. Pertanto, ecco un buon punto di partenza.
Una volta si è in esecuzione con una cache distribuita ed reaping relativi vantaggi, è possibile condividere la nuove sessione di ASP.NET le prestazioni e la scalabilità risultati con il team di sviluppo interni o terze parti, fornitore. Con la prova hardware di disponibilità, è possibile richiedere il team di sviluppo per analizzare le aree in cui sono possibile memorizzare dati dell'applicazione nonché questa cache distribuita.
La memorizzazione nella cache i dati dell'applicazione fornisce un incremento ulteriormente e in molti casi molto più aumenta più semplicemente una cache distribuita per l'archiviazione sessione ASP.NET. Gli sviluppatori si essere in grado di identificare tutti gli elementi di dati vengono letti con maggiore frequenza rispetto a vengono aggiornati. Transazioni anche dati (come clienti, ordini e così via) sono un buon candidato per la memorizzazione nella cache, anche se rimane nella cache per alcuni minuti prima della scadenza. In questo breve periodo di tempo, potrebbero essere rilettura i dati, molte volte, ed è caso questa leggere nuovamente dalla cache e non dal database, alleggerisce il database di un lotto di carico di lettura.
Tuttavia, per gli sviluppatori ai dati di cache dell'applicazione, sarà necessario un po'di programmazione effettuando chiamate ALL'API nella cache distribuita. L'idea è molto semplice. Ogni volta che l'applicazione tenta di recuperare dati dal database, è necessario verificare prima la cache. Se la cache è che i dati, i dati verrà eseguiti dalla cache. In caso contrario, l'applicazione recupera i dati dal database, memorizza nella cache e assegna all'utente. In questo modo, i dati verranno da trovare nella cache la volta successiva che viene letto. Analogamente, ogni volta che nel database vengono modificati i dati, deve inoltre essere aggiornato nella cache. E, se la cache risiede su più server, è necessario pertanto da sincronizzare automaticamente in verificare se l'applicazione viene eseguita in una Web farm, gli stessi dati di cache siano accessibili da tutti i server della farm. Per ulteriori informazioni sull'argomento di sviluppare un'applicazione che utilizza una cache distribuita per migliorare la scalabilità, vedere per mio articolo futura nel numero di luglio di MSDN Magazine.
Khan Iqbal è il presidente e la tecnologia Evangelist di Alachisoft, la società che fornisce NCache, il settore dell'iniziale cache .NET distribuiti per un incremento delle prestazioni e della scalabilità nelle applicazioni enterprise. Iqbal ha ricevuto una Microsoft in informatica presso la University, Bloomington, indiana nel 1990. È possibile contattarlo in iqbal@alachisoft.com.