Sommario:
- Un'introduzione alla vernice
- Nozioni di base: immagini cache
- Lo standard: immagini e pagine della cache
- Lo standard ++: aumentare la resilienza del server
- Uso avanzato: creare un server Web resiliente in un ambiente distribuito
- Uno strumento potente
Quando si tratta di prestazioni del sito Web, Varnish è una tecnologia calda. Con una semplice installazione e configurazione, è possibile migliorare le prestazioni di qualsiasi sito Web e servire fino a un milione di pagine con solo un piccolo server privato virtuale., Ti mostrerò quattro possibili configurazioni che ti aiuteranno a migliorare i tempi di risposta del tuo sito, indipendentemente dal fatto che tu serva centinaia, migliaia o milioni di pagine.
Un'introduzione alla vernice
Varnish-Cache è un acceleratore Web con l'obiettivo di memorizzare nella cache i contenuti del sito Web. È un progetto open source che mira a ottimizzare e accelerare l'accesso ai siti Web in modo non invasivo - senza modificare il codice - e consentire di mettere le mani nel tuo sito Web.
Sono stati i creatori di Varnish Cache a definirlo un acceleratore Web, poiché il suo obiettivo principale è migliorare e accelerare il front-end di un sito Web. Varnish raggiunge questo obiettivo memorizzando copie delle pagine servite dal server Web nella sua cache. La prossima volta che verrà richiesta la stessa pagina, Varnish servirà la copia invece di richiedere la pagina dal server Web, determinando un enorme aumento delle prestazioni.
Un'altra delle caratteristiche principali di Varnish Cache, oltre alle sue prestazioni, è la flessibilità del suo linguaggio di configurazione, VCL. VCL consente di scrivere criteri su come gestire le richieste in arrivo. In tale politica, è possibile decidere quali contenuti si desidera pubblicare, da dove si desidera ottenere i contenuti e in che modo modificare la richiesta o la risposta.
Nei seguenti esempi di configurazione, ti mostrerò quali regole VCL usare per raggiungere alcuni obiettivi, da una semplice memorizzazione nella cache di immagini e oggetti statici, all'utilizzo di Varnish in un ambiente distribuito o al fatto che funga da bilanciamento del carico.
Tutti i seguenti esempi sono per Varnish 3.x. Nota che Varnish 2.x utilizza sintassi e regole diverse, quindi questi esempi non sono compatibili con quella versione.
I seguenti sono gli stati principali di Varnish, che useremo nel file di configurazione VCL:
recv
Questa è la prima funzione che viene chiamata quando si riceve una richiesta. Qui possiamo manipolare la richiesta prima di andare a verificare se è presente nella cache. Se una richiesta non può essere inserita in una cache, in questa fase può essere scelto anche il server back-end a cui verrà inviata la richiesta.
passaggio
Possiamo usare questa funzione quando vogliamo inoltrare la richiesta al server Web e memorizzare nella cache la risposta.
tubo
Questa funzione ignora Varnish e invia la richiesta al server Web.
consultare
Con una ricerca, Varnish chiede di verificare se la risposta è presente e valida nella cache.
andare a prendere
Questa funzione viene chiamata dopo che il recupero del contenuto dal back-end è stato invocato da un passaggio o da un errore.
Nozioni di base: immagini cache
Quindi diamo un'occhiata a un esempio di configurazione. In questo primo esempio, memorizzeremo semplicemente nella cache le immagini e i file statici come i file CSS. Questa configurazione è davvero utile quando non si conosce il sito Web che si desidera potenziare, quindi si può semplicemente decidere che tutte le immagini, CSS e JavaScript sono uguali per tutti gli utenti. Per distinguere gli utenti, il protocollo HTTP utilizza i cookie, quindi dobbiamo eliminarli in questo tipo di richiesta in modo che siano tutti uguali per Varnish:
sub vcl_recv{
if(req.url ~ " * \.(png|gif|jpg|swf|css|js)"{
unset req.http.cookie;
unset req.http.Vary;
return(lookup);
}
# strip the cookie before the image is inserted into cache.
sub vcl_fetch {
if (req.url ~ "\.(png|gif|jpg|swf|css|js)$") {
unset beresp.http.set-cookie;
}
E questo è tutto. Con questo file VCL puoi facilmente memorizzare nella cache contenuti statici.
Lo standard: immagini e pagine della cache
Di solito, non vuoi solo memorizzare nella cache i contenuti statici del tuo sito web, ma vuoi anche memorizzare nella cache alcune pagine dinamiche generate dal tuo server Web, ma che sono le stesse per tutti gli utenti - o almeno per tutti i tuoi anonimi utenti. In questa fase, devi sapere scegliere quali pagine possono essere memorizzate nella cache e quali no.
Un buon esempio è Wordpress, uno dei sistemi di gestione dei contenuti più comunemente utilizzati. Wordpress genera pagine di siti Web in modo dinamico con PHP e interroga un database MySQL. Questo è bello perché puoi aggiornare facilmente il tuo sito Web dall'interfaccia di amministrazione con pochi clic, ma è anche costoso in termini di risorse utilizzate. Perché eseguire lo stesso script PHP e la query MySQL ogni volta che un utente arriva sulla homepage? Possiamo usare Varnish per memorizzare nella cache le pagine più visitate e ottenere risultati incredibili.
Queste sono alcune regole che possono essere utili in un'installazione di Wordpress:
sub vcl_recv{
# Let's make sure we aren't compressing already compressed formats.
if (req.http.Accept-Encoding) {
if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|mp3|mp4|m4v)(\?. * |)$") {
remove req.http.Accept-Encoding;
} elsif (req.http.Accept-Encoding ~ "gzip") {
set req.http.Accept-Encoding = "gzip";
} elsif (req.http.Accept-Encoding ~ "deflate") {
set req.http.Accept-Encoding = "deflate";
} else {
remove req.http.Accept-Encoding;
}
}
if (req.url ~ "^/$") {
unset req.http.cookie;
}
# Unset all cookies if not Wordpress admin - otherwise login will fail
if (!(req.url ~ "wp-(login| admin )")) {
unset req.http.cookie;
return(lookup);
}
# If you request the special pages go directly to them
if (req.url ~ "wp-(login| admin )") {
return (pipe);
}
}
sub vcl_miss {
if (!(req.url ~ "wp-(login| admin )")) {
unset req.http.cookie;
}
if (req.url ~ "^/+.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)(\?.|)$") {
unset req.http.cookie;
set req.url = regsub(req.url, "\?.$", "");
}
if (req.url ~ "^/$") {
unset req.http.cookie;
}
}
sub vcl_fetch {
if (req.url ~ "^/$") {
unset beresp.http.set-cookie;
}
# Unset all cookies if not Wordpress admin - otherwise login will fail
if (!(req.url ~ "wp-(login| admin )")) {
unset beresp.http.set-cookie;
}
}
Potete vedere che in questo esempio, memorizziamo nella cache tutte le pagine del nostro sito Web, ma per quelle che hanno "wp-admin" o "wp-login" nell'URL le stringhe sono posizioni "speciali" utilizzate per accedere Wordpress come amministratore. Pertanto, vogliamo parlare direttamente con il server Web e bypassare la cache di Varnish.
Naturalmente, se usi Drupal, Joomla o un sito Web personalizzato, devi modificare queste regole, ma l'obiettivo è sempre lo stesso: inviare tutte le pagine dinamiche e la cache che puoi al tuo back-end.
Lo standard ++: aumentare la resilienza del server
A volte i server Web diventano lenti perché hanno un carico elevato. Anche la vernice può aiutare in questo. Possiamo usare alcune direttive speciali per dire a Varnish di evitare di parlare con il back-end se è inattivo o sta rispondendo troppo lentamente. Per questi casi Varnish usa la direttiva "grazia".
Grazia nella portata di Vernice significa consegnare oggetti altrimenti scaduti quando le circostanze lo richiedono. Questo può accadere perché:
- Il regista back-end selezionato è inattivo
- Un thread diverso ha già effettuato una richiesta al back-end non ancora completata.
sub vcl_recv {
if (req.backend.healthy) {
set req.grace = 30s;
} else {
set req.grace = 1h;
}
}
sub vcl_fetch {
set beresp.grace = 1h;
}
Questa configurazione dice a Varnish di testare il back-end e aumentare il periodo di tolleranza in caso di problemi. L'esempio sopra introduce anche la direttiva "req.backend.healthy", che viene utilizzata per controllare un back-end. Questo è davvero utile quando hai più back-end, quindi diamo un'occhiata a un esempio più avanzato.
Uso avanzato: creare un server Web resiliente in un ambiente distribuito
Questo è il nostro file di configurazione finale con tutte le opzioni che abbiamo visto finora e la definizione di due back-end con qualche direttiva speciale per il probe. Ecco come Varnish determina se un server Web è vivo o meno.
.url
Varnish farà richieste al back-end con questo URL.
.tempo scaduto
Determina la velocità con cui deve terminare la sonda. È necessario specificare un'unità di tempo con un numero, ad esempio "0, 1 s", "1230 ms" o anche "1 h".
.intervallo
Quanto tempo aspettare tra i sondaggi. È necessario specificare un'unità di tempo anche qui. Si noti che questa non è una "tariffa" ma un "intervallo". Il tasso di polling più basso è (.timeout + .interval).
.finestra
Quanti degli ultimi sondaggi considerare quando si determina se il back-end è integro.
.soglia
Quanti degli ultimi sondaggi .window devono essere validi affinché il back-end sia dichiarato sano.
Ora possiamo usare la direttiva "req.backend.healthy" e ottenere un risultato booleano che ci dice se i back-end sono vivi o meno.
#
# Customized VCL file for serving up a Wordpress site with multiple back-ends.
#
# Define the internal network subnet.
# These are used below to allow internal access to certain files while not
# allowing access from the public internet .
acl internal {
"10.100.0.0"/24;
}
# Define the list of our backends (web servers), they Listen on port 8080
backend web1 { .host = "10.100.0.1"; .port = "8080"; .probe = { .url = "/status.php"; .interval = 5s; .timeout = 1s; .window = 5;.threshold = 3; }}
backend web2 { .host = "10.100.0.2"; .port = "8080"; .probe = { .url = "/status.php"; .interval = 5s; .timeout = 1s; .window = 5;.threshold = 3; }}
# Define the director that determines how to distribute incoming requests.
director default_director round-robin {
{ .backend = web1; }
{ .backend = web2; }
}
# Respond to incoming requests.
sub vcl_recv {
set req.backend = default_director;
# Use anonymous, cached pages if all backends are down.
if (!req.backend.healthy) {
unset req.http.Cookie;
set req.grace = 6h;
} else {
set req.grace = 30s;
}
# Unset all cookies if not Wordpress admin - otherwise login will fail
if (!(req.url ~ "wp-(login| admin )")) {
unset req.http.cookie;
return(lookup);
}
# If you request the special pages go directly to them
if (req.url ~ "wp-(login| admin )") {
return (pipe);
}
# Always cache the following file types for all users.
if (req.url ~ "(?i)\.(png|gif|jpeg|jpg|ico|swf|css|js|html|htm)(\?+)?$") {
unset req.http.Cookie;
}
}
# Code determining what to do when serving items from the web servers.
sub vcl_fetch {
# Don't allow static files to set cookies.
if (req.url ~ "(?i)\.(png|gif|jpeg|jpg|ico|swf|css|js|html|htm)(\?+)?$") {
# beresp == Back-end response from the web server.
unset beresp.http.set-cookie;
}
# Allow items to be stale if needed.
set beresp.grace = 6h;
}
Uno strumento potente
Questi sono solo alcuni esempi che possono aiutarti a iniziare a usare Varnish. Questo strumento è davvero potente e può aiutarti a ottenere un notevole incremento delle prestazioni senza acquistare altro hardware o macchine virtuali. Per molti amministratori di siti Web, questo è un vero vantaggio.
