Infrastruttura Web
ASP.NET Web Cache Spurs prestazioni e scalabilità
Iqbal Khan
Informazioni di riepilogo:
- Collo di bottiglia notevole riduzione
- Statica e dinamica memorizzazione nella cache Web
- Le funzionalità sono: scadenze, database più dipendenza, PDF parziale del contenuto,
- Vantaggi speciali per le organizzazioni globali
- Cluster di server cache Web
- Soluzioni gratuite e commerciali
Il problema: I colli di bottiglia ASP.NET
Della soluzione: Cache Web ASP.NET
Funzionalità di disponibilità del necessario in Cache Web
Scadenze
Ricaricare pagine su scadenze
Cache di pagine parziale
Dipendenza di database
Dipendenza di file
Contenuto parziale di PDF
Cache di ViewState
Compressione gzip
Cluster di Cache Web scalabile e dinamico
Distribuzione geografica di cache
Rimanere stoccaggio dal database
Linee guida
Applicazioni basate su ASP.NET, il framework di applicazione Web di Microsoft, effettuano inroads maggiore nell'organizzazione. Allo stesso tempo, colli di bottiglia dovuti all'aumento del numero di utenti e le transazioni si continuano a richiedere i professionisti IT per chiamare per migliorare le prestazioni e scalabilità.
Il problema: I colli di bottiglia ASP.NET
I colli di bottiglia possono verificarsi in applicazioni ASP.NET per una serie di motivi. Il più ovvio: tecnologia di archiviazione di dati non è come scalabile come architettura di applicazioni Web. Qualsiasi posizione in un'applicazione ASP.NET che gestisce immediatamente con archiviazione dei dati o di accesso ai dati diventa un logjam quando si tenta di scalare l'applicazione. Due aree in cui in questo caso sono dati di archiviazione e l'applicazione di stato sessione da un database relazionale o mainframe (vedere la Figura 1 ).
Figura 1 colli di bottiglia aree comuni di prestazioni in applicazioni ASP.NET.
Un altro collo di bottiglia si verifica se l'applicazione ASP.NET in esecuzione servizio-orientato alla architettura (SOA) le chiamate a servizi Web. In questo caso, il rallentamento si verifica perché i servizi Web hanno gli stessi problemi dell'applicazione ASP.NET (vale a dire, di archiviazione dei dati e l'accesso). Probabilità sono una farm di servizi Web è condivisa tra più applicazioni e, pertanto, in sovraccarico molto più di qualsiasi un'applicazione ASP.NET, creando il collo di bottiglia scalabilità.
I colli di bottiglia può inoltre verificarsi tra il browser dell'utente e la farm Web di ASP.NET. Questi clogs riguardano il fatto che le pagine ASP.NET da eseguire ripetutamente in fase di riguardanti l'elaborazione della CPU elevato. Questo processo prevede inoltre inviare elementi di dati ad alta densità (immagini, documenti, e così via) e nuovamente nuovamente all'utente.
In una precedente TechNet Magazine articolo, ho descritto i problemi di prestazioni e scalabilità ASP.NET, con particolare attenzione lo stato della sessione e i dati dell'applicazione (vedere" Fornire la scalabilità per applicazioni ASP.NET"Giugno 2009). In questo articolo, ho parlato di come tali problemi, inclusi i motivi che ASP.NET Session State diventa un logjam man mano che aumenta una Web farm. È stato descritto il fatto che distribuita cache in memoria rappresenta un'alternativa superiore a Microsoft di esistente opzione di archiviazione per lo stato sessione di ASP.NET. È stato descritto come i dati di applicazioni provenienti da un database possono causare colli di bottiglia a livello di scalabilità. Dettagliate come distribuite risolve la memorizzazione nella cache i colli di bottiglia archiviazione stato sessione ASP.NET con l'aiuto di topologie di memorizzazione nella cache diverse che ogni offrono diverse funzionalità, ma tutti indirizzo scalabilità e garantire tempi di attività pari al 100 %.
Infine, in genere considerate i diversi distribuito le opzioni disponibili in commercio di cache. Alcune opzioni sono liberi con funzionalità limitate, mentre altri sono più affidabili e ricco di funzionalità prodotti. Tuttavia, per migliore le prestazioni e scalabilità, la prudente prendere in considerazione prodotti all'inizio della riga.
Della soluzione: Cache Web ASP.NET
Definizione di tale problema come sfondo, lo stato attivo primario di questo articolo è sulle prestazioni e scalabilità dei colli di bottiglia tra il browser dell'utente e il server Web o Web farm. In teoria, si desidera ridurre il numero di volte in cui viene eseguita la pagina Web stessa. Se la pagina Web viene eseguita una volta e l'output non modifica anche brevemente, perché eseguirla nuovamente? Perché non è sufficiente memorizzare nella cache l'output? La volta successiva che un utente può solo recuperare output della pagina direttamente dalla cache, anziché riesecuzione. Riesecuzione della pagina comporta la CPU, utilizza una quantità di memoria e che utilizza altre risorse del server Web, e quindi, naturalmente, sono presenti i problemi di scalabilità collo di bottiglia dall'archivio dati.
Output di una pagina ASP.NET nella cache dello stesso server Web, Microsoft fornisce il meccanismo di cache di output di ASP.NET che consentono di eseguire questa operazione e funziona anche. Tuttavia, si dispone due problemi sulla cache di output di ASP.NET.
Innanzitutto, richiede consentono di modificare il codice ASP.NET e, come minimo, inserire i tag in queste pagine per indicare che si desidera memorizzare nella cache l'output. Non è sempre possibile per persona una IT che gestisce sviluppate internamente sia esternamente acquistato applicazioni ASP.NET. Inoltre, ogni volta che si modifica il codice dell'applicazione, è necessario accedere tramite sforzi di controllo di qualità per assicurarsi che non ha interrotto il processo. Ciò aumenta i costi di inserimento nella cache.
In secondo luogo, cache di output di ASP.NET memorizza nella cache locale per ogni server Web e, in effetti, all'interno di ogni processo di lavoro ASP.NET output della pagina. Se si dispone un Web garden (vale a dire più processi di lavoro su un server Web) o di una Web farm con bilanciamento del carico, viene creato problemi principali in termini di coerenza e la scalabilità. In questi casi sono presenti più copie disconnesse della cache, per il traffico elevato siti Web, questo potrebbe diventare un incubo di gestione. In ASP.NET 4.0, Microsoft è promessa un framework di memorizzazione nella cache estensibile che consente di mantenere la cache in un processo separato o di un livello incorporando una cache distribuita di terze parti.
Alla luce di questo sviluppo, si desidera la cache di output della pagina non sul server Web, ma in un server cache Web separato che si trova tra utenti e Web farm (tipo di un proxy inverso, ad esempio, vedere la Figura 2 ). Se numerose richieste dell'utente non renderla la Web farm e viene trasferite da una cache in tra, invece, si sta riduzione del carico per la Web farm e aumentare la scalabilità della Web farm. Recupero output di una pagina Web dalla cache e restituirlo all'utente è necessario richiede decisamente meno risorse rispetto a effettivamente l'esecuzione di tale pagina Web. Ciò accade perché la cache è un archivio in memoria a elevate prestazioni e scalabilità, a differenza di qualsiasi spazio su disco che può avere problemi di prestazioni e scalabilità.
Nella figura 2 server di cache Web seduta tra utenti e server Web.
In questo contesto, verrà illustrato come la memorizzazione nella cache l'output di pagine Web risolvere colli di bottiglia e migliorare notevolmente scalabilità e prestazioni. Un server di cache Web può rivestire un ruolo nel raggiungimento di tali obiettivi.
Un server di cache Web vengono intercettate le richieste http effettuate dagli utenti per le pagine Web e controlli se output tali pagine esiste già nella cache. In caso affermativo, il server di cache Web restituisce che all'utente di output. La richiesta dell'utente consente mai anche ai server Web. Poiché di recuperati dalla cache, il valore restituito è estremamente rapido. E poiché è in memoria e la pagina non deve essere re-executed, una grande quantità di elaborazione della CPU viene salvata anche.
Un server di cache Web possibile lavorare con qualsiasi piattaforma di tecnologia Web back-end. Purché siano tutti talking HTML e JavaScript, non importa se l'applicazione Web è sviluppato Java,. NET, PHP o un'altra lingua. Tuttavia, un server di cache Web può includere alcune funzionalità specifiche della piattaforma, in modo che funzionalità diverse da una soluzione per soluzione.
Esistono due tipi di soluzioni di caching Web. Una cache principalmente dati relativamente statici, vale a dire che ogni pagina nella cache è presume che sia completamente statici o di modificare intervalli prevedibili. La pagina intera è memorizzata nella cache per un determinato periodo di tempo, dopo il quale è possibile scade e viene rimosso dalla cache. L'altro tipo è per la cache dinamico più appropriato per siti Web dinamici o applicazioni Web.
Se l'applicazione sito Web o Web è dinamico, in cui dati vengono modificati spesso e in modo imprevedibile, è necessario scegliere per il caching dinamico. Tali giorni, la maggior parte dei siti Web modificare almeno alcuni dei relativi contenuti spesso. È possibile memorizzare nella cache qualcosa di appena 15 ai 30 secondi, ma in genere per in qualsiasi punto da alcuni minuti per alcune ore e in alcuni casi, per giorni o anche settimane.
La memorizzazione nella cache Web offre un vantaggio importante grandi aziende in tutto il mondo: la possibilità di geograficamente disperdere la memorizzazione nella cache Web Server. In un'organizzazione globale, l'applicazione sito Web principale può essere ospitato in New York, ma è necessario agli utenti tutto il mondo, San Francisco e Londra e Tokyo e Sydney e Dubai. Ora è facile relativamente la memorizzazione nella cache Web server geograficamente disponibili in ciascuna di queste aree. Tutte le richieste provenienti da Europa verranno passare attraverso il server di cache di Web Europa prima che il sito Web di accessi al. In questo modo, questi non necessario cross Oceano il Nord e comportare la latenza di 100 millisecondi che deve passare attraverso ogni pacchetto. Sono sostanzialmente possibile ottenere una copia di esso da una cache adiacente.
Diamo un altro esempio. Si dispone di un server in Dubai che gestiscono le aree del Medio Oriente e in Asia meridionale e avere centinaia di migliaia di utenti di raggiungere il sito Web contemporaneamente. Con la cache Web, il traffico verso il centro dati principale di Milano eliminerà in modo significativo. Non tutto il traffico è stato arrestato perché è non memorizzare nella cache tutti gli elementi e qualsiasi sono cache viene anche rimosso dalla cache (che è, invalidata) in momenti. Ma a seconda della natura dell'applicazione, probabilmente si è ridotto il traffico 30 e 50 percento.
Funzionalità di disponibilità del necessario in Cache Web
Con il passare del tempo, siti Web hanno trasformato di visualizzare solo contenuto statico per diventare completamente interattive di applicazioni Web con dati dinamici che vengono modificati frequentemente. Che significa che, oggi, una cache Web deve soddisfare tutti i requisiti di un sito Web dinamico. L'obiettivo è da memorizzare nella cache parte il sito Web contenuto possibile, mentre allo stesso tempo garantendo che il contenuto della cache sia corretto e non non aggiornati o uscita di non sincronizzazione con i dati sottostanti nel database. Per gestire tutto questo, è necessario che la cache Web alcune funzionalità per evitare problemi dell'integrità dei dati durante l'incremento di prestazioni e scalabilità.
Una soluzione di cache Web tipica include le seguenti funzionalità.
Scadenze
Funzionalità di scadenza consente di specificare le regole sulle pagine Web da memorizzare nella cache e la durata. E consente di pagine scadenza ora assoluta o variabile. Tempo assoluto, significa che si prevede di scadenza di un elemento in un determinato momento, se è mezzanotte di oggi o 10 minuti dall'ora. Scorrimento ora varia a seconda se una determinata pagina costantemente accede. Se non è in si accede a una pagina, se non è viene utilizzato affatto, si desideri scadenza. Un tempo di inattività si scade una pagina se non visualizzato utilizzato per più di un determinato periodo di tempo, ad esempio, 10 o 20 minuti.
Assoluto-data di scadenza è probabilmente all'ora di scadenza per le pagine Web più importante. Prodotti di caching Web consentono di specificare le regole e scegliere i modelli di URL (nota come "URI") da memorizzare nella cache. La memorizzazione nella cache Web consente di specificare che alcuni URL non deve mai essere inserita nella cache. Consente di specificare determinati tipi di URL nella cache per un determinati periodi di tempo.
È necessario consentono inoltre di specificare quando la scadenza dei vari URL basati sulle informazioni fornite nelle intestazioni HTTP, fornito con l'output di URL. Intestazione HTTP della pagina in ogni è in possibile di contengono informazioni quanto tempo è possibile memorizzare nella cache, quando scade, e quando è stata apportata l'ultima modifica. Questi sono gli elementi Web cache possibile verificare per controllare se il contenuto di una pagina è stata modificata e se è necessario caricare nuovo contenuto nella cache. Senza questa funzionalità non è necessario un modo per invalidare e rimuovere i dati non aggiornati.
Ricaricare pagine su scadenze
Un'altra funzionalità importante è la capacità di automaticamente ricarica una pagina di scadenza per qualsiasi motivo, se a causa di scadenza assoluto o periodi di inattività. Ad esempio, potrebbe essere: "la pagina è utile per i prossimi 20 minuti." Dopo 20 minuti, la cache Web re-fetches automaticamente la pagina in modo da sempre la copia più recente.
In questo modo, non attendere per la successiva richiesta dall'utente per la pagina. Ecco perché quando la richiesta, non si desidera che l'utente può passare attraverso il ritardo per il recupero nuovamente tale pagina dalla Web farm. Poiché è possibile recuperare, in background, potrebbe richiedere è da 5 a 10 secondi per recuperare, dal server Web mediante l'esecuzione prima. Ma che va bene, poiché al momento che l'utente ottiene, sarà possibile restituirlo con un tempo di risposta sottosecondi seconda come distante l'utente.
Cache di pagine parziale
Alcune delle pagine visualizzate in un browser contiene più elementi ciascuno con il proprio URL. Pertanto per una pagina di cui eseguire il rendering, è necessario chiamare il browser Web più URL. Questo raggiunge lo stesso risultato parziale della pagina, ma non è chiamato "pagina parziale" perché sul lato server, ciascun URL rappresenta una pagina e ogni pagina viene memorizzata nella cache in modo indipendente e per una durata diversa, a seconda della natura del relativo contenuto.
In altre situazioni, un singolo Web pagina è stata sviluppata in tale modo il contenuto è suddiviso in sezioni. Alcune sezioni sono statici e non cambiano, alcune parti sono dinamici, con ciascuna parte di modifica dopo un intervallo diverso. In effetti, le sezioni pagina parziale della pagina per la memorizzazione nella cache cache basato su se siano statico o dinamico e per memorizzati nel tempo deve essere cache, anziché solo la cache l'intera pagina.
ASP.NET consente di eseguire l'inserimento di parziale-pagine nella cache tramite due meccanismi: controllare la memorizzazione nella cache e post-cache sostituzione. Sia necessario modificare le pagine ASP.NET specifica in cui si desidera eseguire la memorizzazione nella cache. Che potrebbe non essere possibile se non si dispone di proprie risorse di sviluppo e la è non sviluppare l'applicazione ASP.NET interna. Ciò nonostante, segue una descrizione di ogni tipo di memorizzazione nella cache parziale della pagina in ASP.NET.
È possibile eseguire parziale della pagina la memorizzazione nella cache in ASP.NET tramite creazione di controlli utente per il contenuto memorizzato nella cache e quindi contrassegnare i controlli utente "memorizzabile nella cache." Consente di memorizzare nella cache alcune parti della pagina come controlli utente in modo che quando la pagina è re-executed, tali parti siano semplicemente recuperati dalla cache e non re-executed. Solo quelle parti della pagina che non sono designati come controlli utente e non sono contrassegnate come "può essere memorizzata nella cache sono re-executed."
Con la sostituzione post-cache, la pagina memorizzata nella cache, ma alcune parti o frammenti in essa contenuti verranno contrassegnate "dinamico" o non memorizzabile nella cache. Quando questa pagina viene rieseguita, quindi, vengono eseguite effettivamente solo le parti dinamiche o non memorizzabile nella cache. Il resto della pagina viene ottenuto dalla cache e dinamici e memorizzati nella cache parti vengono combinate per restituire l'output della pagina.
È interessante notare che la memorizzazione nella cache parziale-pagina può essere eseguita solo sul server Web. Per questo motivo, alcune programmazione è necessario. Nel caso di ASP.NET, la memorizzazione nella cache parziale-pagina avviene tramite programmazione nelle pagine ASP.NET per determinare e quali No, da memorizzare nella cache. Ma la memorizzazione nella cache viene eseguita sul server Web stesso e ancora esegue almeno pagina ASP.NET, parti di esso.
In ASP.NET, la memorizzazione nella cache parziale-pagina, invece, è implementata in base a specifiche di Microsoft, ma la piattaforma Java, è emersa una parziale della pagina nella cache standard denominato lato servizio include (ESI). ESI definisce un linguaggio di markup basato su XML semplice che definisce i componenti di pagina Web può essere memorizzata nella cache e non memorizzabile nella cache che possono essere aggregati, raccolto e consegnati al margine della rete, se è in una rete di recapito di contenuto, il browser dell'utente finale o un server di cache Web che agisce come un proxy inverso tra browser degli utenti e il server Web.
In questo modo, la memorizzazione nella cache parziale-pagina è altamente specifico della piattaforma, naturalmente, per ASP.NET, è necessario utilizzare approccio di Microsoft.
Dipendenza di database
Un'altra funzionalità chiave è la dipendenza di database, che consente a una pagina per essere invalidato dalla cache quando il corrispondente output dati in modifiche del database. La pagina viene spesso generato output basato su dati di database. I dati che sono rappresentazione che provengono da una o più righe in una o più tabelle di database. Di conseguenza, se modificano le righe, queste pagine devono essere rimosso dalla cache. Per questo motivo, la sincronizzazione del database è un'importante funzionalità. Ciò significa che quando i dati cambiano nel database, output di queste pagine deve essere invalidato e deve essere rimosso dalla cache. Questa funzionalità consente di determinare automaticamente quando determinate pagine devono essere rimosso dalla cache.
Per creare questa dipendenza è possibile specificare un'istruzione "select" di SQL (o una chiamata di stored procedure contenente un'istruzione select) che corrisponde alla pagina in questione, quindi il mapping di alcuni dei parametri GET o POST pagina con i parametri nell'istruzione SQL. In fase di esecuzione, i parametri della pagina Web vengono utilizzati per eseguire l'istruzione SQL, e un oggetto SqlCacheDependency è creare riferimento a un SQL Server 2005/2008 o Oracle 10 g R2 database o versione successiva. Quindi quando la riga corrispondente nel database viene modificato, il server di database genera un evento di .NET che viene ricevuto dal server di cache Web. Quindi la pagina Web corrispondente output viene rimosso dalla cache (vedere la Figura 3 ).
Nella figura 3 pagina rimosso dalla cache di Web se database le modifiche di riga.
Dipendenza di file
Un'altra funzionalità chiave è dipendenza di file. È possibile associare un output di pagina con un file nel sistema con le istruzioni: "Se questo file viene mai aggiornato o rimosso, vedere invalidare questa pagina." Quindi, la cache Web controlla tale file, che si trova in una cartella condivisa. Se tale file viene mai aggiornato o rimosso, la cache Web invalida automaticamente l'URL corrispondente dalla cache. Questo consente di aggiornare che file da un punto qualsiasi nel sistema, se comporta un'altra applicazione o anche un trigger nel server di database basato su quando alcuni correlati che le modifiche apportate ai dati. Ad esempio, se i dati sono memorizzati in un mainframe anziché in database di SQL 2005/2008 o Oracle, è possibile utilizzare una dipendenza di file da invalidare una pagina nella cache.
Tutto ciò consente di notificare alla cache quando invalidare se determinate operazioni verificano nell'archivio dati o nel proprio ambiente, che non sono accessibili direttamente dalla cache del Web.
Contenuto parziale di PDF
Ora accedere a molte persone in linea i file PDF. Il modello di utilizzo comune è che leggere una pagina alla volta, scorrere l'intero file PDF da una pagina. Alcuni utenti scaricare un intero PDF e quindi leggere localmente; più leggerlo nel browser. Quando si stanno visualizzando le informazioni in questo modo, vengono in genere non leggere l'intero documento, sono stato abbandonare dopo aver ottenuto tramite la parte di esso.
In modo che gestiscono l'intero file PDF è spesso uno spreco di risorse, in realtà Impossibile il fattore di differenziazione tra le prestazioni di accettabile e accettabile durante le ore di punta. Per questo motivo, la gestione di contenuto parziale di PDF è una funzionalità importante in una cache Web. Riduce il carico della larghezza di banda sul server Web e migliora la scalabilità complessiva.
Cache di ViewState
Tra i più importanti funzionalità di ASP.NET è la possibilità di dichiarare controlli che vengono eseguiti sul server e post-back alla stessa pagina. Prima per ASP.NET, in ASP classico, è terminato di creare più pagine per gestire operazioni diverse che, logicamente, appartenevano a una pagina, ad esempio, il caricamento dei dati, salvare i dati o eseguire altre azioni. Ma in ASP.NET è non è più necessario eseguire questa operazione. Campi modulo e altri controlli possono essere dichiarati ora per eseguire sul server e il server di restituire semplicemente la pagina a se stesso.
Per gestire questi post-backs, viene creato un ViewState che memorizza l'identità dei controlli e le informazioni dinamiche assegnati a questi controlli. In sostanza, ViewState mantiene lo stato di controllo di una pagina attraverso più post.
ViewState è importante per le applicazioni ASP.NET. In sostanza, di informazioni inviate da tale server al browser in modo che il browser può inviare le stesse informazioni al server all'utente di tempo successivo esegue un post per la stessa pagina.
Ad esempio, si può caricare un cliente nella pagina customer.aspx. Quindi, si apportare alcune modifiche nei dati del cliente e si fare clic su "Salva". Il pulsante Salva nuovamente chiama customer.aspx, ma invia anche il ViewState in modo che il customer.aspx sa come gestire questo tipo di postback. ViewState contiene le informazioni che customer.aspx aveva inviato al browser e il postback contenga i nuovi dati l'utente ha probabilmente modificato. Che consente di customer.aspx determinare cosa è cambiato e sulle operazioni da eseguire su di esso. Si tratta di un semplice esempio, ViewState può inoltre contenere altri dati creati dinamicamente per ogni controllo nella pagina.
Sebbene sia estremamente utile in ASP.NET il ViewState, comporta anche costi di trasferimento dei dati e Indietro da un server Web a browser dell'utente. Questo costo potrebbe disporre di un prestazioni e la scalabilità impatto durante carichi di picco di applicazione e quando gli utenti sono lontano dal server Web e una connessione Internet lenta.
Ma il ViewState non è spesso di viaggi per il browser se è possibile essere memorizzato nella cache Web. In tale caso, solo un tag o un ID univoco può essere inviato al browser in modo che se il browser viene nuovamente, la cache Web necessario reinserire un ViewState e fornire nuovamente al server Web basato sull'ID univoco. Tutti i server richiede un Web è il browser invia la richiesta, alla successiva contenente il ViewState dal momento precedente. Indipendentemente dal fatto che ViewState raggiunge il browser in quanto il browser non utilizza mai le informazioni, è solo il server Web.
In termini tecnici, un ViewState viene utilizzato per il postback, in caso mai post-backs, sarà necessario un ViewState, e una cache Web può memorizzare nella cache un ViewState. Che consente inoltre di una notevole larghezza di banda, perché un ViewState potrebbe essere pochi kilobyte in dimensioni.
Compressione gzip
Tali giorni, la maggior parte dei browser possibile decomprimere il contenuto di compressione gzip. Ma non tutti i server Web sono configurati per comprimere automaticamente output delle pagine Web. E anche se la compressione è attiva, utilizza numerosi CPU non necessaria in ogni server Web, che è già in corso di sovraccarico da traffico elevato. Tuttavia, se la compressione è eseguita da un server proxy intermedi di cache Web, diventa più scalabile.
È particolarmente semplice comprimere i dati statici non viene mai modificato. Tuttavia, la maggior parte delle pagine in un'applicazione di ASP.NET sono dinamiche e il contenuto deve essere compresso solo se l'output della pagina non modifica ogni volta. In caso contrario, compressione dovrà inserire un carico consiglia una quantità di spazio su CPU, forse dwarfing i vantaggi dell'utilizzo della larghezza di banda. Ma, poiché una cache Web è già intelligente sulle capire quali output di pagine dinamiche è inseribile nella cache (significato che non cambiano per almeno un breve periodo di tempo), è inoltre in grado di comprimere automaticamente tutte le pagine della cache. Queste pagine nella cache vengono trasferite ai client più volte in formato compresso quindi notevolmente ridotto utilizzo della larghezza di banda.
Una compressione gzip tipica riduce il contenuto di quasi 80 %, a meno che il contenuto è già compresso (ad esempio, PDF, JPEG, TIFF, e così via.). Una buona cache Web deve consentire all'utente di specificare quale URL per comprimere e che ignorare per la compressione.
Cluster di Cache Web scalabile e dinamico
Una cache Web è un server che si trova davanti a una farm Web ASP.NET (quasi come un'apparecchiatura). Oggi, ASP.NET Web farm possono aumentare da due server a 100-plus server con un sistema di bilanciamento del carico. Di conseguenza, un singolo server di cache Web è Impossibile gestire il carico di una Web farm crescente. Una buona regola generale è che per ogni cinque server della farm Web, è necessario un server di cache Web.
Presenza di più server di cache Web non solo migliora la scalabilità, ma consente inoltre la cache Web per la replica in modo che se qualsiasi un server si arresta o viene eseguito verso il basso, la cache non viene persa e non una riduzione delle prestazioni (vedere non c'è Nella figura 4 ).
Nella figura 4 cluster cache Web dinamico (aggiungere o rimuovere i server in fase di esecuzione).
Un server di cache Web buona necessario creare un cluster di server la memorizzazione nella cache Web per gestire l'affidabilità mediante la replica e la scalabilità attraverso più server. Tuttavia, sono coinvolti molti la memorizzazione nella cache-server Web, è ancora considerato una cache Web logica. Anche se non esistono più copie della cache nel cluster, è sempre mantenute sincronizzate. In breve, con un cluster di server di caching Web consente scala mantenendo la correttezza logica della cache.
Una volta ottenuto un cluster cache, una cache Web buona dovrà consentire di specificare diverse opzioni memorizzazione in cache, nota anche come memorizzazione nella cache le topologie. Le topologie principale includono replicata cache, cache partizionata e cache del client.
Replicate significa cache l'intera cache viene copiato ogni server di cache del cluster. Di conseguenza, ogni server di cache è l'intera cache. Tutte le operazioni "get" sono sempre locali a tale finestra e, di conseguenza, sono molto veloce. Tuttavia, gli aggiornamenti vengono apportati più server di cache e se esistono più di due di tali server nel cluster, aumenta del costo di aggiornamento quindi.
D'altra parte, cache partizionata interruzioni (o partizioni) la cache, memorizzazione di ogni partizione su un server di cache diverso. Il numero di partizioni è pari il numero di server di cache. Questo consente di aumentare capacità di archiviazione cache aggiungendo più server di cache, non nella cache replicato. Inoltre partizione cache consente di creare backup di ogni partizione su un server di cache diverso in modo che se uno qualsiasi dei tali server viene interrotto, non perdere la cache. Cache di partizione è la topologia di memorizzazione nella cache più scalabile per archiviazione e transazioni al secondo.
Infine, la cache del client è una topologia che è combinata con partizionate o cache replicato, (soprattutto se la cache effettiva è ospitata in un server diverso dal server di cache Web). Cache client mantiene un piccolo sottoinsieme della cache all'interno del processo del client in modo che i dati utilizzati di frequente siano sempre disponibili chiudere da. Cosa è tenuto nella cache del client dipende da quali client recuperati di recente. È possibile specificare una dimensione massima per il client di cache in modo che quando si raggiunge la dimensione, viene avviato rimuovere (o rimuovere) gli elementi meno recenti in modo da liberare spazio per nuovi. In questo modo, la cache del client non utilizza più memoria rispetto a ciò che si è stabilito fattibile.
Se si utilizzano più server di cache Web senza la creazione di un cluster cache, è necessario terminare con più copie disconnesse della cache. Tale risultato può essere accettabile se il sito Web è piuttosto statico, ma per siti Web dinamici e le applicazioni ASP.NET, che potrebbe causare problemi dell'integrità dei dati. Inoltre, si verrà finisce inviare la richiesta dell'utente al server Web anche se un altro server di Cache Web è l'output di questa pagina nella cache, aumentando il carico della farm Web ASP.NET.
Distribuzione geografica di cache
Applicazione ASP.NET molti siti Web oggi hanno gli utenti in tutto il mondo anche se il sito Web ospitato in un'unica posizione. È spesso Impossibile per il sito Web da individuare in più aree geografiche a causa della complessità e al costo dell'infrastruttura. Ad esempio, una farm Web ASP.NET deve inoltre avere un server di database nella stessa posizione, i server di database non sono in genere è ideali per la distribuzione geografica quando comportano applicazioni altamente transazionali. Di conseguenza, gli utenti finali riduzione delle prestazioni a causa della latenza di rete WAN wide area.
Un modo per risolvere tale problema è collocare i server di cache Web in ogni sede geografica, quindi inviare tutto il traffico da tale area tramite il server di cache Web più vicino (vedere la Figura 5 ). Quindi se un server di cache Web non dispone di una pagina già memorizzata nella cache, invia direttamente la richiesta al centro dati principale, in cui si trova un altro insieme di cache Web Server.
Nella figura 5 distribuiti geograficamente cache Web server in ambiente.
In modo che una cache Web buona deve abbia la possibilità di creare una gerarchia di server in modo che ogni cache Web dove indirizzare la richiesta, anche se la pagina memorizzata nella cache non ha.
Rimanere stoccaggio dal database
Come illustrato nel mio articolo di giugno 2009, dati non modificati ogni volta, mentre rimane costante. Sfortunatamente, senza memorizzazione nella cache distribuita, si ha intenzione a cicli non necessari per riprodurre ripetutamente gli stessi dati. Ma, non è necessario passare tutto il tempo del database. Si tratta gli stessi dati, così perché passare non esiste? Perché non necessario dalla cache?
Di seguito è un esempio per evidenziare il problema. Pagina web principale di una compagnia aerea non modifica la maggior parte, può essere memorizzati nella cache per un lungo periodo di tempo. Un cliente le visite alla ricerca di voli. Le informazioni sono costantemente lo spostamento perché come altri utenti Rubrica posti, le informazioni di modificano sul back-end.
Se il cliente sta cercando, ad esempio, un volo da New York a San Francisco, disponibilità postazione determina i risultati. Postazione disponibilità dipende dal numero di utenti già prenotati con prenotazioni eseguite costantemente. Un businessperson harried potrebbe complicare questioni di immissione di informazioni non corrette o selezionando più voci per garantire l'assegnazione di una postazione.
L'utente riceve i risultati che indica che un volo specifico è disponibile, con le informazioni di modifica nella cache ogni cinque minuti. Ma una volta che il cliente desidera effettivamente riservare una postazione, quindi un controllo in tempo reale viene eseguito nel database. Significa che per ogni 1.000 utenti cercare disponibilità volo, probabilmente solo circa 10 creare effettivamente un impegno. Si tratta di fine visualizzare la disponibilità di volo per i visitatori, anche se le informazioni fornite non è completamente corrette. In tali situazioni, è possibile memorizzare nella cache la pagina anche se è estremamente dinamico.
Ma è possibile memorizzare con l'idea è accettabile per fornire informazioni con alcuni rischi che non quello completamente accurato. Nella pagina prenotazioni del database, tuttavia, la fondamentale per assicurarsi che tutte le informazioni siano accurato e aggiornato. Il punto è che ogni applicazione dispone di informazioni comuni che possono essere memorizzati nella cache e un utente del sito Web non deve essere inviato al database la compagnia aerea ogni volta.
La fase più semplice è quando si desidera memorizzare nella cache tutte le immagini. Non modificare il logo della società del presidente di immagine o documenti standard che avete disponibili per utenti. Ma esistono altre parti sono più dinamiche. In cui è possibile specificare le regole e si supponga, ad esempio, "si desidera memorizzare nella cache in questa pagina per questo lungo."
Con altre pagine, potrebbe essere "non è possibile capire quanto l'utilizzo per la memorizzazione nella cache, quindi desidera, collegare al database. Se questa riga in questa tabella viene modificato, utilizzare questa pagina per essere invalidato. Ciò significa che rimosso dalla cache e ricaricare, creare una nuova copia. Ogni categoria di pagina è diverso. Purché una cache Web consente di determinare come si desidera pagine della cache, si sta creando una situazione in cui più nella cache, minore passare alla farm Web.
Linee guida
Nella maggior parte dei casi, è possibile ottenere vantaggi significativi distribuendo cache Web. Se avete solo un server Web, è probabile che non è sufficiente il traffico si verifichino questi tipi di problemi. Ma se 1.000 o più utenti, si dispone probabilmente già di una Web farm a carico bilanciato. In questo caso, si è un candidato per l'esplorazione modi per ottimizzare le prestazioni e scalabilità.
Pianificare in anticipo. Non attendere che i problemi a verificarsi perché una volta in tal caso, sarà in modalità panic. Il momento migliore è quando non sono i principali problemi che devono affrontare, ma a questo punto, è necessario essere in grado di indurre l'alta dirigenza su perché è necessario il finanziamento per un progetto. Un buon metodo per raggiungere tale obiettivo: richiesta di gestione quale potrebbe essere costo azienda se il sito Web fornito tempi di risposta questo lenta durante ore di punta (upward del 30 a 60 secondi per fare clic su). E cosa succede se il sito Web arrestato per 30 a 60 minuti? Considerando queste domande può aiutare a convincere i dirigenti dell'organizzazione sulla necessità di una cache Web.
Come sottolineato in precedenza da un servizio di stampa esterna sia disponibile la memorizzazione nella cache Web opzioni disponibili. Con crescente popolarità ASP.NET tra gli sviluppatori, opzioni esterna la memorizzazione nella cache Web che supportano. NET sono ora emergenti. In questo articolo, tuttavia, la maggior parte dei prodotti di caching Web supportano Java e PHP. La maggior parte sono basate sul software, ma sono disponibili anche alcune opzioni apparecchiatura di hardware.
Come si considerino le scelte effettuate, rimanere focalizzati su organizzazione e sito Web. Dinamico è il sito? Quanti utenti sono disponibili? La quantità di cache verrà praticità?
È opportuno considerare le funzionalità di memorizzazione nella cache è necessario. Come già illustrato, la memorizzazione nella cache consente di transazioni questi veloce e scalabile. Ma talvolta possibile assegnare informazioni obsolete di utenti. Tenere presente che saldo come è prendere in considerazione varie soluzioni.
Esamina Khan è il presidente e Technology Evangelist di Alachisoft. Alachisoft fornisce NWebCache, ovvero una cache Web ASP.NET iniziale per aumentare le prestazioni e la scalabilità. Esamina ha ricevuto un M.S. laurea in informatica presso la University Indiana, Bloomington, nel 1990. È possibile contattarlo all'indirizzo Iqbal@Alachisoft.com.