Varnish Cache est un accélérateur HTTP et proxy inverse développé par un consultant danois et développeur de base de FreeBSD Poul-Henning Kamp ainsi que d'autres développeurs de Norwegian Linpro AS . Il a été publié en 2006.
Selon Pingdom.com une société axée sur la performance web, Varnish était déjà célèbre en 2012 parmi les meilleurs sites web au monde pour sa capacité à accélérer la livraison web , et il a été utilisé par des sites tels que Wired, SlideShare, Zappos, SoundCloud, Météo.com, Business Insider, Answers.com, Dictionnaire urbain, MacRumors, DynDNS, OpenDNS, Lonely Planet, Technorati, ThinkGeek et Economist.com. 19659003] Il est autorisé en vertu d'une licence BSD à deux clauses . Varnish a un niveau supérieur, Varnish Plus axé sur les clients d'entreprise, qui offre des fonctionnalités supplémentaires, des modules et un support .
Bien qu'il existe d'autres solutions shine Varnish est toujours une solution de choix qui peut considérablement améliorer la vitesse du site Web, réduire la pression sur le processeur du serveur d'applications Web et même servir de couche de protection contre les attaques DDoS . KeyCDN recommande de le déployer sur la pile du serveur d'origine.
Varnish peut s'asseoir sur une machine dédiée en cas de sites web plus exigeants, et s'assurer que les serveurs d'origine ne sont pas affectés par le flot de requêtes.
Au moment d'écrire ces lignes (novembre 2017), Varnish est à la version 5.2 .
Comment ça marche
Caching fonctionne en général en gardant les sorties pré-calculées de une application en mémoire ou sur le disque, de sorte que les calculs coûteux ne doivent pas être calculés encore et encore à chaque requête. Web Cache peut être sur le client (cache du navigateur) ou sur le serveur. Le vernis tombe dans la deuxième catégorie. Il est généralement configuré de sorte qu'il écoute les requêtes sur le port HTTP standard (80), puis qu'il serve la ressource demandée au visiteur du site Web.
La première fois qu'une certaine L'URL et le chemin sont demandés, Varnish doit le demander au serveur d'origine afin de le servir au visiteur. C'est ce qu'on appelle un CACHE MISS, qui peut être lu dans les en-têtes de réponse HTTP, selon la configuration de vernis.
Selon les docs
quand un objet, n'importe quel type de contenu ou une page, n'est pas stockée dans le cache, alors nous avons ce qui est communément connu comme un cache manquant, auquel cas Varnish ira chercher le contenu du serveur web, le stocker et en remettre une copie à l'utilisateur et le conserver dans le cache pour servir en réponse à de futures requêtes.
Lorsqu'une URL particulière ou une ressource est mise en cache par Varnish et stockée en mémoire, elle peut être servie directement à partir de la RAM du serveur; il n'a pas besoin d'être calculé à chaque fois. Varnish commencera à délivrer un CACHE HIT en quelques microsecondes
Cela signifie que ni notre serveur d'origine ni notre application web, y compris sa base de données, ne sont touchés par de futures requêtes. Ils ne seront même pas au courant des demandes chargées sur les URLs mises en cache.
Le serveur d'origine – ou les serveurs, au cas où nous utiliserons Varnish comme équilibreur de charge – sont configurés pour écouter sur une non-standard port, comme 8888, et Varnish est mis au courant de leur adresse et port .
Caractéristiques du vernis
Le vernis est enfilé . Il a été rapporté que Varnish était capable de gérer plus de 200 000 requêtes par seconde sur une seule instance. Si elle est correctement configurée, les seuls goulots d'étranglement de votre application Web seront le débit du réseau et la quantité de RAM. (Cela ne devrait pas être une exigence déraisonnable, car il suffit de garder les pages Web calculées en mémoire, donc pour la plupart des sites Web, quelques gigaoctets suffisent.)
Le vernis est extensible via VMODS . Ce sont des modules qui peuvent utiliser des bibliothèques C standard et étendre les fonctionnalités de Varnish. Il y a VMODS de la communauté a énuméré ici . Ils vont de la manipulation d'en-tête à l'écriture de scripts Lua, à la limitation des requêtes, à l'authentification, etc.
Varnish possède son propre langage spécifique au domaine, VCL . VCL fournit une configurabilité complète. Avec un serveur de mise en cache de page pleine comme Varnish, il y a beaucoup de subtilités qui doivent être résolues
Lorsque nous mettons en cache un site web dynamique avec des dizaines ou des centaines de pages Avec les paramètres de requête GET, nous souhaitons exclure certains d'entre eux du cache ou définir des règles d'expiration de cache différentes. Parfois, nous voulons mettre en cache certaines requêtes Ajax, ou les exclure du cache. Cela varie d'un projet à l'autre et ne peut pas être adapté à l'avance.
Parfois, nous demanderons à Varnish de décider quoi faire de la requête en fonction des en-têtes de la requête. Parfois, nous voudrons passer directement les demandes à l'arrière avec un certain ensemble de cookies.
Pour citer le livre Varnish
VCL fournit des sous-programmes qui vous permettent d'affecter le traitement de n'importe quel single. Requête presque n'importe où dans la chaîne d'exécution.
Purger le cache doit souvent être fait dynamiquement – déclenché par la publication d'articles ou la mise à jour du site Web. La purge doit également être aussi atomique que possible – ce qui signifie qu'elle doit cibler la plus petite portée possible, comme une seule ressource ou un seul chemin.
Cela signifie que les règles spécifiques doivent être définies en fonction de leur ordre de priorité. Quelques exemples peuvent être trouvés dans le livre de vernis (qui est disponible pour lire en ligne ou en tant que PDF téléchargeable ).
Varnish a un ensemble de outils pour surveiller et administration du serveur :
-
Il y a
varnishtop
qui nous permet de surveiller les URL demandées et leur fréquence. -
varnishncsa
peut être utilisé pour imprimer le Varnish Shared Memory Log (VSL): il déverse tout ce qui pointe vers un certain domaine et sous-domaines. -
varnishhist
lit le VSL et présente un histogramme en direct montrant la distribution du dernier nombre de requêtes, donnant une vue d'ensemble du serveur et du sous-domaine. -
varnishtest
est utilisé pour tester les fichiers de configuration VCL et développer VMODS. -
varnishstat
affiche des statistiques sur notre instance de varnishd: -
varnishlog
est utilisé pour obtenir des données sur un clie spécifique
Varnish Software propose un ensemble de solutions commerciales payantes, soit sur le cache de Varnish, soit sur son utilisation et son aide à la surveillance et à la gestion: Varnish Api Engine Vernis prolongé Connecteur Akamai pour vernis Console d'administration de vernis (VAC) et Vernis de statistiques personnalisées (VCS) . Vernis
Les documents vernis couvrent l'installation sur divers systèmes . Nous irons avec Ubuntu 16.04 LTS dans ce post.
Packagecloud.io a des instructions pour la mise à jour des dépôts Ubuntu et l'installation de Varnish version 5:
curl -L https://packagecloud.io / varnishcache / vernis5 / gpgkey | sudo apt-key ajouter -
sudo apt-get mise à jour
sudo apt-get installer -y apt-transport-https
Ensuite, nous ajoutons les lignes suivantes au fichier nouvellement créé /etc/apt/sources.list.d/varnishcache_varnish5.list
:
deb https://packagecloud.io/varnishcache/varnish5 / ubuntu / xenial principal
deb-src https://packagecloud.io/varnishcache/varnish5/ubuntu/ xenial main
Puis nous courons:
sudo apt-get mise à jour
sudo apt-get installer vernis
Nous pouvons tester une toute nouvelle installation de WordPress fonctionnant sous Nginx. Tout d'abord, nous changeons le port d'écoute par défaut de Nginx de 80 à 8080 – qui est le port que Varnish attend du back-end – en ajoutant les lignes suivantes à l'hôte virtuel Nginx, à l'intérieur de la clause server:
server {
écoute 127.0.0.1:8080 default_server;
écouter [::]: 8080 default_server;
Ensuite, nous configurons Varnish: nous éditons / etc / default / vernish
en remplaçant le port 6081 par 80 (le port web par défaut):
DAEMON_OPTS = "- a: 80
-T localhost: 6082
-f /etc/varnish/default.vcl
-S / etc / vernis / secret
-s malloc, 256m "
Nous devons aussi changer /lib/systemd/system/varnish.service
en faisant le même remplacement:
[Service]
Type = simple
LimitNOFILE = 131072
LimitMEMLOCK = 82000
ExecStart = / usr / sbin / varnishd -j unix, utilisateur = vcache -F -a: 80 -T localhost: 6082 -f /etc/varnish/default.vcl -S / etc / vernish / secret -s malloc, 256m
ExecReload = / usr / share / vernish / reload-vcl
ProtectSystem = complet
ProtectHome = true
PrivateTmp = true
PrivateDevices = true
Puis nous redémarrons Nginx et Varnish:
sudo service nginx restart
sudo /etc/init.d/varnish restart
Attention: en raison de certaines particularités, Varnish doit généralement être redémarré – ou démarré de cette façon, non avec service vernn start
– afin de lire tous les fichiers de configuration que nous avons édités.
Nous avons testé la rapidité et la réactivité du site avec Locust et Pingdom Tools .
Une fois le cache chauffé, la différence était impressionnante, bien que Nginx soit bien connu pour ses speed: le nombre moyen de requêtes par seconde a été multiplié par trois à quatre fois et le temps de réponse a été considérablement réduit. Les temps de chargement étaient un peu plus élevés en raison de la latence du réseau, puisque nous avons testé le site hébergé en Californie depuis un poste de travail en Europe.
Nocif:
Résultats acridiens pour Nginx + Vernis:
Les résultats de Pingdom étaient également bons.
Résultats de Pingdom pour la pile Nginx, testés de California:
Résultats Pingdom pour Nginx + Vernis, Californie:
Notez vous aussi le TTFB pour chaque cas
Nginx seul:
Nginx + Vernis: [19659003]
Même si nous négligeons la partie rose, qui est la recherche DNS, il y a toujours une différence évidente.
Simplicité de Setu p
Varnish se fout de ce qui écoute sur le port 8080 (nous pouvons aussi changer ce port par défaut, si nécessaire). Cela signifie que la configuration d'Apache, ou d'un autre serveur d'application, devrait être aussi simple: tout ce que nous devons faire est de les configurer pour écouter sur le port 8080 au lieu de 80.
Configurer Varnish avec NodeJS
serveur existant, où nous avions déjà installé Varnish, la mise en place d'une application Node hello-world était tout aussi simple. Nous avons installé les paquets nodejs
et npm
et lié NodeJS au noeud:
ln -s / usr / bin / noeudjs / usr / bin / noeud
Puis nous avons créé un simple noeud hello-world programme écoutant sur le port 8080:
#! / Usr / bin / env nodejs
var http = require ('http');
http.createServer (function (req, res) {
res.writeHead (200, {'Content-Type': 'text / plain'});
res.end ('Hello World n');
}). listen (8080, 'localhost');
console.log ('Serveur tournant à http: // localhost: 8080 /');
Puis nous avons installé le gestionnaire de paquets de Node, PM2 pour pouvoir démoniser notre application:
sudo npm install -g pm2
pm2 démarrer index.js
aAnd voila – notre application Node était servie par Varnish:
Autres astuces
Pour pouvoir contrôler si notre requête est mise en cache dans notre navigateur inspecteur, nous devons ajouter l'extrait suivant à notre fichier de configuration Varnish, dans le bloc sub vcl_deliver
:
sub vcl_deliver {
if (obj.hits> 0) {
set resp.http.X-Cache = "HIT";
} autre {
set resp.http.X-Cache = "MISS";
}
}
Ensuite, nous pouvons voir les commentaires dans nos en-têtes de réponse comme HIT ou MISS :
Encore un avertissement: Vernis (ou au moins l'open- version source) ne supporte pas SSL réitéré à nouveau par son créateur Poul-Henning Kamp (qui n'est pas timide pour exprimer ses opinions ). Donc, quand vous avez besoin d'utiliser Varnish et HTTPS, envisagez d'utiliser un autre proxy en face avant terminaison SSL – comme haproxy ou le propre attelage de Varnish . 19659003] Ou, si cela devient trop compliqué, utilisez simplement Nginx et FastCGI Cache .
Conclusion
Dans cet article, nous avons essayé de donner une brève introduction à Varnish Cache sans trop entrer dans sa configuration
L'optimisation des performances du serveur est une science qui lui est propre et la présentation de tous les cas d'utilisation et de toutes les configurations nécessite un autre article. Je vais plonger un peu plus profondément dans ce sujet dans un autre article, alors restez à l'écoute pour un prochain épisode, où j'ajouterai Varnish devant une vraie application.
Source link