Di recente è stato detto molto il merito dei siti statici . Ma in molte situazioni un approccio dinamico è una necessità. Che si tratti di un sistema di gestione dei contenuti, di uno strumento di relazione con i clienti o di un negozio online, consentono agli utenti finali di mantenere siti complessi in modo rapido e coerente. E quando messi insieme, possono rivaleggiare con siti statici per la velocità.
qualsiasi applicazione che debba leggere e scrivere frequentemente dati causerà un ritardo notevole
Qualunque sia il sistema che usi, i siti dinamici in genere comprendono elementi simili. Si tratta di una forma di server Web, un back-end e un'applicazione, scritti in uno o più linguaggi di programmazione. Questa combinazione di componenti offre una grande flessibilità, ma ognuno contribuisce al proprio overhead e aumenta il tempo di caricamento, cosa che tutti i siti Web moderni vogliono evitare. Ciò è particolarmente vero con l'accesso al database: qualsiasi applicazione che debba leggere e scrivere frequentemente dati causerà un ritardo notevole.
In questo modo sarà utile la memorizzazione nella cache e una strategia di memorizzazione nella cache appropriata per il tuo caso d'uso. L'obiettivo principale della memorizzazione nella cache è impedire chiamate inutilmente frequenti tra i livelli del database dell'applicazione e utilizzare invece pagine HTML statiche pre-generate, che sono molto più veloci da eseguire in un browser.
La prima cache che qualsiasi utente web avrebbe notato è la cache nel browser. Quante volte gli sviluppatori ti hanno chiesto di eseguire un "aggiornamento forzato" per visualizzare le modifiche? Le cache del browser sono semplici ma un buon punto di partenza per iniziare a spiegare i concetti di memorizzazione nella cache. Un browser memorizza le rappresentazioni delle pagine Web visitate sul computer dell'utente, in genere aggiornandole una volta per sessione se le modifiche vengono rilevate o forzate dal sito.
Uno strumento comune utilizzato dai proprietari e dagli amministratori del sito è una 'cache del proxy inverso' che si trova tra le richieste di pagina effettuate da un browser Web e dall'applicazione web. Intercetta richieste e rende copie di pagine direttamente dalla cache, fornendo così un notevole aumento di velocità.
Esistono diverse opzioni principali della cache proxy disponibili per l'installazione automatica o come "Software come servizio". (Stiamo ignorando i provider di hosting di cloud che in genere includono tutto ciò che potrebbe essere necessario in uno stack Web autonomo.)
Le opzioni popolari della cache proxy includono:
Le opzioni SaaS per la memorizzazione nella cache si trovano in genere nel mondo di Content Delivery Network (CDN) che invece di posizionare una cache tra un utente e uno stack Web serve agli utenti set di contenuti memorizzati nella cache che sono geograficamente più vicini a loro. È una differenza sottile, ma che per grandi siti con un pubblico globale può fare una differenza significativa.
Vernice è disponibile in tutti i gestori di pacchetti Linux, come immagine Docker e molte altre opzioni, leggi il pagina di installazione del progetto per ulteriori dettagli.
Varnish memorizza un file di configurazione predefinito su /usr/local/etc/varnish/default.vcl o /etc/varnish/default.vcl , scritto in VCL (Lingua di configurazione di vernice). Questo file di configurazione viene compilato in un piccolo programma tramite un interprete C per aumentare ulteriormente la velocità.
A seconda di come hai installato Varnish, il file di configurazione sarà simile a questo:
backend default {.host = "127.0.0.1";.port = "8000";}Al più semplice, questo definisce il backend predefinito usato da Varnish, definendo l'host e la porta che dovrebbe ascoltare e intercettare il contenuto.
Una funzione utile di Varnish è il controllo a intervalli predefiniti se un back-end è ancora sano. Si chiama 'Backend Polling' e viene configurato aggiungendo una sezione probe nella dichiarazione di backend:
.probe = {.url = '/';.timeout = 34ms;.interval = 1s;.window = 10;.threshold = 8;}Quanto sopra sono le impostazioni predefinite fornite da Varnish e le dicono di visitare un particolare .url ogni .interval e che, se per almeno .simali fuori dalle sonde .window , l'url risponde entro .timeout millisecondi, il backend è ancora considerato sano. Una volta considerato 'malsano', il contenuto viene servito dalla cache per un periodo predefinito.
Copriremo specifiche modifiche alla configurazione di Varnish sotto ogni opzione di piattaforma, per ora diamo un'occhiata alle opzioni generali.
Ports
Inizialmente, la porta per il server Web dovrà essere modificata rispetto a quella predefinita. Ad esempio, nella configurazione di Apache Vhost, modificare la porta su 81 o 8080.
Avvia il demone Varnish con il comando varnish o usando un service wrapper. Il demone ha opzioni di flag, il più comune e utile essere:
Il controllo sta funzionando
Esegui il comando varnishstat o visita isvarnishworking.com per verificare che il server di Varnish sia pronto e in ascolto delle richieste.
Cosa non memorizzare nella cache
Ci sono alcune parti di un sito che non vogliamo memorizzare nella cache, ad esempio le pagine di amministrazione. Possiamo escluderli creando una subroutine vcl_recv nel file default.vcl contenente un'istruzione if che definisce cosa non memorizzare nella cache:
sub vcl_recv {# URI of admin folderif (req.url ~ "^/url/"){return (pass);}return(lookup);}Se si utilizza Varnish 4, le cose sono leggermente diverse, inclusi i valori di ritorno. La funzione vcl_recv restituisce ora un valore hash invece di una ricerca.
sub vcl_recv {...return(hash);}Questo è anche il luogo in cui impostiamo siti o sottodomini che Varnish dovrebbe ignorare aggiungendo un req.http.host ~ 'esempio.com' all'istruzione if .
Biscotti
Per impostazione predefinita, Varnish non memorizza nella cache il contenuto del backend che imposta i cookie. Allo stesso modo, se il client invia un cookie, bypasserà Varnish direttamente sul back-end.
I cookie vengono spesso utilizzati dai siti per tenere traccia delle attività degli utenti e memorizzare i valori specifici dell'utente. Generalmente questi cookie interessano solo il codice lato client e non interessano il back-end o la Varnish. Possiamo dire a Varnish di ignorare i cookie, tranne in particolari aree del sito:
if ( !( req.url ~ ^/admin/) ) {unset req.http.Cookie;}Questa dichiarazione if ignora i cookie a meno che non ci troviamo nell'area di amministrazione del sito, dove il passaggio dei cookie potrebbe essere più utile (a meno che non si voglia veramente frustrare gli amministratori del sito).
Altre eccezioni
Con un'installazione predefinita, Varnish inoltre non memorizza nella cache le pagine protette da password, le richieste GET e HEAD.
Vedremo ora due casi d'uso perfetti per Varnish: Drupal e Magento. Entrambi sono sistemi altamente dinamici che consentono agli utenti non tecnici di intraprendere una vasta gamma di compiti complessi. Ciò può portare a carichi di pagine pesanti per le query del database e i siti occupati diventeranno notevolmente lenti. Le pagine tipiche create con questi sistemi avranno una miscela di contenuti aggiornati di rado e di frequente.
Drupal ha opzioni di caching predefinite che svolgono funzioni simili a Varnish, ma non fornisce la flessibilità o gli aumenti di velocità richiesti da siti più grandi o più complessi.
Nella vera maniera di Drupal c'è a modulo per la gestione dell'integrazione di vernice per salvare parte della configurazione manuale descritta sopra.
Installare il modulo e assicurarsi di seguire le istruzioni di installazione incluse nel file Leggimi del modulo.
Assicurati che il file / etc / default / varnish abbia le seguenti opzioni di demone impostate (e che il rientro sia importante):
DAEMON_OPTS="-a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,128M"Assicurarsi che Apache e gli host virtuali associati siano in ascolto sulla porta 8080, non 80. Riavviare entrambi i servizi dopo aver apportato queste modifiche.
Potrebbe essere necessario impostare un "tasto di controllo della vernice" nella pagina di configurazione del modulo. Scopri qual è la chiave con il comando cat / etc / varnish / secret e incollalo nella pagina delle impostazioni. Seleziona la versione di Varnish corretta, salva le impostazioni e dovresti vedere una serie di segni di spunta verdi nella parte inferiore della pagina.
Il modulo Varnish interagisce con le impostazioni predefinite della cache Drupal, quindi assicurati di averlo abilitato e configurato per il tuo caso d'uso.
Esegui varnishstat dalla riga di comando, inizia a navigare nel sito come utente anonimo e dovresti vedere le statistiche che cambiano nell'output del comando.
Uno dei percorsi che non vogliamo memorizzare nella cache in Drupal sono le pagine di amministrazione, possiamo farlo con una sub-routine vcl_recv :
sub vcl_recv {# URI of admin folderif (req.url ~ "^/admin/"){return (pass);}unset req.http.Cookie;return(lookup);}Potresti considerare di non memorizzare nella cache le pagine utente (registrate), le pagine di aggiornamento del sistema e altre pagine generate da moduli altamente dinamici come il flag che fanno ampio uso di ajax per funzionare. Fatelo aggiungendo ulteriori parametri req.url all'istruzione if .
Un'installazione predefinita di Magento viene fornita con un sistema di memorizzazione nella cache interno che memorizza le versioni statiche degli elementi del sito in una cartella specificata. La pagina Sistema -> Gestione cache fornisce una panoramica dello stato corrente della cache e consente di cancellare tutte le cache di singoli componenti o singole. È possibile cancellare file CSS e JS aggregati e file di immagini generate automaticamente da questa pagina.
La prossima versione 2 di Magento supporterà il caching di Varnish di default, ma per ora abbiamo bisogno di usare plugin di terze parti, raccomando il Modulo di trementina . Assicurati di leggere il file readme del progetto come nota alcuni passaggi di configurazione aggiuntivi, ignorarli potrebbe interrompere il tuo sito.
Il modulo Turpentine è altamente configurabile e apporta le modifiche necessarie ai file vcl e alla configurazione di Varnish. Alcune opzioni chiave da impostare sono:
Il modulo Turpentine si collega alla cache Magento predefinita, quindi cancellando le cache nella pagina della cache di Varnish si cancelleranno le cache della Varnish pertinenti.
Oltre all'uso di Varnish con uno qualsiasi dei sistemi dinamici di cui sopra, ecco una manciata di altri suggerimenti vari che aiuteranno la cache-capacità di qualsiasi sito.
Se stai servendo lo stesso contenuto in diversi contesti, dovrebbe utilizzare lo stesso URL. Ad esempio, non mescolare l'uso di article.html , article.htm e article , sebbene il CMS possa consentirlo. Ciò porterà a tre diverse versioni memorizzate nella cache dello stesso contenuto.
Come abbiamo visto sopra, i cookie sono difficili da memorizzare nella cache e raramente sono necessari quanto pensiamo. Cerca di limitare il loro uso e numero alle pagine dinamiche.
Il caricamento delle risorse del sito può essere una delle parti che richiedono più tempo di un rendering di pagine e ci sono semplici suggerimenti per ridurre questo onere:
L'uso degli sprite CSS per l'iconografia anziché di più file di piccole dimensioni comporta un minor traffico di rete.
Ospitare localmente le librerie CSS e JavaScript significa meno traffico di rete e maggior controllo sulle strategie di caching. Questo può significare un aumento dei costi di manutenzione per mantenere questi asset aggiornati. Archiviare queste risorse in cartelle con nomi coerenti in modo che i riferimenti a esse possano anche essere coerenti.
Spero che questa introduzione per velocizzare i siti dinamici con il caching sia stata utile. Il guadagno in termini di prestazioni vale un periodo iniziale di configurazione, sperimentazione e messa a punto. In questa era di scarsa attenzione e impazienza, qualsiasi guadagno di velocità che si può spremere dal set up farà la differenza per gli utenti e la concorrenza.
Immagine in evidenza, immagine della cache di rete via Shutterstock.