Table des matières:
- Une introduction au vernis
- Les bases: images cache
- La norme: images et pages en cache
- Le standard ++: augmenter la résilience du serveur
- Utilisation avancée: créer un serveur Web résilient dans un environnement distribué
- Un outil puissant
En ce qui concerne les performances du site Web, Varnish est une technologie chaude. Avec une installation et une configuration simples, il est possible d'augmenter les performances de n'importe quel site Web et de servir jusqu'à un million de pages avec seulement un petit serveur privé virtuel., Je vais vous montrer quatre configurations possibles qui vous aideront à améliorer le temps de réponse de votre site, que vous diffusiez des centaines, des milliers ou des millions de pages.
Une introduction au vernis
Varnish-Cache est un accélérateur Web dont le but est de mettre en cache le contenu d'un site Web. Il s'agit d'un projet open source qui vise à optimiser et accélérer l'accès aux sites Web de manière non invasive - sans changer le code - et vous permet de mettre la main sur votre site Web.
Ce sont les créateurs de Varnish Cache qui l'ont appelé un accélérateur Web, car son objectif principal est d'améliorer et d'accélérer le front-end d'un site Web. Varnish y parvient en stockant des copies des pages servies par le serveur Web dans son cache. La prochaine fois que la même page sera demandée, Varnish servira la copie au lieu de demander la page au serveur Web, ce qui améliorera considérablement les performances.
Une autre des caractéristiques clés de Varnish Cache, en plus de ses performances, est la flexibilité de son langage de configuration, VCL. La VCL permet d'écrire des politiques sur la façon dont les demandes entrantes doivent être traitées. Dans une telle stratégie, vous pouvez décider du contenu que vous souhaitez diffuser, d'où vous souhaitez obtenir le contenu et comment la demande ou la réponse doit être modifiée.
Dans les exemples de configuration suivants, je vais vous montrer les règles VCL à utiliser pour atteindre certains objectifs, de la simple mise en cache des images et des objets statiques à l'utilisation de Varnish dans un environnement distribué ou en le faisant agir comme un équilibreur de charge.
Tous les exemples suivants concernent le vernis 3.x. Veuillez noter que Varnish 2.x utilise une syntaxe et des règles différentes, donc ces exemples ne sont pas compatibles avec cette version.
Voici les principaux états de Varnish, que nous utiliserons dans le fichier de configuration VCL:
recv
Il s'agit de la première fonction appelée lors de la réception d'une demande. Ici, nous pouvons manipuler la requête avant d'aller vérifier si elle est présente dans le cache. Si une demande ne peut pas être placée dans un cache, le serveur principal auquel la demande sera envoyée peut également être choisi dans cette phase.
passer
Nous pouvons utiliser cette fonction lorsque nous voulons transmettre la demande au serveur Web et mettre en cache la réponse.
tuyau
Cette fonction contourne Varnish et envoie la demande au serveur Web.
Chercher
Avec une recherche, Varnish demande de vérifier si la réponse est présente et valide dans le cache.
aller chercher
Cette fonction est appelée après que la récupération de contenu à partir du back-end est invoquée par une passe ou un échec.
Les bases: images cache
Regardons donc un exemple de configuration. Dans ce premier exemple, nous allons simplement mettre en cache les images et les fichiers statiques comme les fichiers CSS. Cette configuration est vraiment utile lorsque vous ne connaissez pas le site Web que vous souhaitez booster, vous pouvez donc simplement décider que toutes les images, CSS et JavaScript sont les mêmes pour tous les utilisateurs. Afin de distinguer les utilisateurs, le protocole HTTP utilise des cookies, nous devons donc les éliminer dans ce type de requête afin qu'ils soient tous les mêmes pour 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;
}
Et c'est tout. Avec ce fichier VCL, vous pouvez facilement mettre en cache du contenu statique.
La norme: images et pages en cache
Habituellement, vous ne voulez pas seulement mettre en cache le contenu statique de votre site Web, mais vous voulez également mettre en cache certaines pages dynamiques qui sont générées par votre serveur Web, mais qui sont les mêmes pour tous les utilisateurs - ou du moins pour tous vos anonymes utilisateurs. Dans cette phase, vous devez savoir choisir quelles pages peuvent être mises en cache et lesquelles ne le peuvent pas.
Un bon exemple est Wordpress, l'un des systèmes de gestion de contenu les plus couramment utilisés. Wordpress génère des pages de site Web dynamiquement avec PHP et interroge une base de données MySQL. C'est bien parce que vous pouvez facilement mettre à jour votre site Web à partir de l'interface d'administration en quelques clics, mais c'est aussi cher en termes de ressources utilisées. Pourquoi exécuter le même script PHP et la même requête MySQL chaque fois qu'un utilisateur atterrit sur la page d'accueil? Nous pouvons utiliser Varnish pour mettre en cache les pages les plus visitées et obtenir des résultats incroyables.
Voici quelques règles qui peuvent être utiles dans une installation 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;
}
}
Vous pouvez voir que dans cet exemple, nous mettons en cache toutes les pages de notre site Web, mais pour celles qui ont "wp-admin" ou "wp-login" dans l'url, les chaînes sont des emplacements "spéciaux" utilisés pour se connecter à Wordpress en tant qu'administrateur. En tant que tel, nous voulons parler directement au serveur Web et contourner le cache Varnish.
Naturellement, si vous utilisez Drupal, Joomla ou un site Web sur mesure, vous devez changer ces règles, mais l'objectif est toujours le même: envoyer toutes les pages dynamiques et le cache à votre back-end.
Le standard ++: augmenter la résilience du serveur
Parfois, les serveurs Web deviennent lents car ils ont une charge élevée. Le vernis peut aussi vous aider. Nous pouvons utiliser certaines directives spéciales pour dire à Varnish d'éviter de parler avec le serveur principal s'il est en panne ou répond trop lentement. Pour ces cas, Varnish utilise la directive "grace".
La grâce dans le cadre du vernis signifie la livraison d'objets expirés autrement lorsque les circonstances l'exigent. Cela peut arriver parce que:
- Le directeur principal sélectionné est en panne
- Un thread différent a déjà fait une demande au serveur principal qui n'est pas encore terminé.
sub vcl_recv {
if (req.backend.healthy) {
set req.grace = 30s;
} else {
set req.grace = 1h;
}
}
sub vcl_fetch {
set beresp.grace = 1h;
}
Cette configuration indique à Varnish de tester le back-end et d'augmenter la période de grâce en cas de problème. L'exemple ci-dessus présente également la directive "req.backend.healthy", qui est utilisée pour vérifier un serveur principal. C'est vraiment utile lorsque vous avez plusieurs back-ends, alors jetons un coup d'œil à un exemple plus avancé.
Utilisation avancée: créer un serveur Web résilient dans un environnement distribué
Il s'agit de notre fichier de configuration final avec toutes les options que nous avons vues jusqu'à présent et la définition de deux backends avec une directive spéciale pour la sonde. C'est ainsi que Varnish détermine si un serveur Web est vivant ou non.
.url
Varnish fera des requêtes au back-end avec cette URL.
.temps libre
Détermine la vitesse à laquelle la sonde doit terminer. Vous devez spécifier une unité de temps avec un nombre, comme "0, 1 s", "1230 ms" ou même "1 h".
.intervalle
Combien de temps attendre entre les sondages. Vous devez également spécifier ici une unité de temps. Notez que ce n'est pas un "taux" mais un "intervalle". Le taux d'interrogation le plus bas est (.timeout + .interval).
.fenêtre
Le nombre des derniers sondages à prendre en compte pour déterminer si le back-end est sain.
.seuil
Combien de sondages .window doivent être bons pour que le back-end soit déclaré sain.
Nous pouvons maintenant utiliser la directive "req.backend.healthy" et obtenir un résultat booléen qui nous indique si le ou les back-end sont vivants ou non.
#
# 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;
}
Un outil puissant
Ce ne sont que quelques exemples qui peuvent vous aider à commencer à utiliser Varnish. Cet outil est vraiment puissant et peut vous aider à améliorer vos performances sans acheter plus de matériel ou de machines virtuelles. Pour de nombreux administrateurs de sites Web, c'est un réel avantage.
