Varnish
devant Apache
Une nouvelle instance, une cache en avant du web, et des chiffres qui fondent : le laboratoire 2 de l'Application distribuée.
420-5A4-MT · Acte 5 · Le cacheCornucopia · Encyclopédie Bio & Recettes
Accueillir des centaines de milliers de visiteurs sur 500 fiches conseils avec photos et instructions de préparation.
- Pages fortement consultées mais très peu modifiées.
- Requêtes répétitives sur les mêmes articles d'encyclopédie.
Rush 500 000 vis/j : Varnish devant WordPress !
Sur le terrain
500 000 visiteurs par jour
Le serveur PHP/MySQL recalcule des milliers de fois par minute exactement la même page HTML pour des visiteurs différents !
Rapport du terrain
Temps de réponse de 2.5 secondes par page, processeur du serveur web à 100 % d'utilisation constante.
Déployer Varnish HTTP Cache devant le site de Cornucopia pour servir les pages enregistrées en mémoire vive en 2 millisecondes !
La mission du jour
À la fin de la séance, vous aurez :
- Une instance varnish30 qui offre le service de cache Varnish en avant de votre serveur HTTP.
- L'URL d'accès de WordPress modifiée pour utiliser l'adresse du serveur Varnish.
- Le montage mesuré au test de charge BRUTAL (partie 3 du tableau).
- Le tout dans Git : /votre-depot/cache/ (le guide README.md et un sous-dossier par instance).
Prérequis : votre instance WordPress tout-en-un, fonctionnelle - on la nomme http20 pour la suite du module (référence : 192.168.56.20). Sa base de données vit encore avec elle : la séparation viendra la semaine prochaine, derrière Varnish, sans que le cache s'en aperçoive. Minimum 2 commits pertinents en classe cette semaine.
Varnish : la cache en avant
Ajoutez à votre ensemble d'instances existant, avec les mêmes caractéristiques :
- Une instance qui offre le service de cache Varnish en avant de votre serveur HTTP (apache).
- Modifiez l'URL d'accès de WordPress pour utiliser l'adresse du serveur Varnish.
Mesures : test de charge BRUTAL avec JMeter, captures top à 10 et 60 secondes (performances_partie_3_10secondes.png, performances_partie_3_60secondes.png), tableau rempli (id par instance, temps moyen JMeter).
Barème : guide d'installation (2), fichiers de configuration (1), tableau rempli (1), captures d'écran (1).
Minimum 2 commits pertinents en classe durant la semaine 6; le reste avant le cours de la semaine 7. Ce laboratoire doit être entièrement terminé pour le début de la semaine 7.
Varnish
Varnish
La mise en place
- Ajouter le service suivant à votre ensemble de serveurs existants avec les mêmes caractéristiques précédentes :
- Un serveur qui offre le service de cache Varnish en avant de votre serveur HTTP (apache).
- Modifier l'URL d'accès de WordPress pour utiliser l'IP du serveur varnish.
Le test de charge BRUTAL
- Faire un test de charge BRUTAL avec JMeter pour documenter les performances de votre ensemble de serveurs actuel.
- Faire une seule capture d'écran statique de la commande top exécutée en ssh de tous les serveurs actifs après environ 10 secondes de test (performances_partie_3_10secondes.png).
- La même chose après environ 60 secondes de test (performances_partie_3_60secondes.png).
- Noter dans un tableau la valeur idle du processeur (id) pour chaque serveur.
- Noter dans un tableau la valeur moyenne (temps moyen de réponse) indiquée par JMeter.
La nouvelle instance et Varnish
Rappel clonage : nouvelle adresse MAC, nouveau nom d'hôte (varnish30), nouvelle adresse IP. Un clone qui garde l'identité de son parent sème le chaos sur le réseau.
Varnish prend le port 80
Le pare-feu de varnish30 s'ouvre au strict nécessaire : le port 80 pour les visiteurs, le 22 pour vous.
Le backend, et Apache qui se replie
WordPress déménage officiellement
- Modifier l'URL d'accès pour utiliser l'adresse du serveur Varnish : c'est elle, la nouvelle adresse du site.
- Tester depuis le navigateur de l'hôte : le site répond par l'adresse de varnish30.
- Rechargez la même page plusieurs fois, puis regardez varnishstat : les hits grimpent, Apache respire.
La preuve par les chiffres
- Test de charge BRUTAL avec JMeter, visant l'adresse de Varnish.
- Captures top en SSH de TOUTES les instances actives : performances_partie_3_10secondes.png et performances_partie_3_60secondes.png
- Remplir la ligne 3 du tableau : id de mysql10, http20 et varnish30, temps moyen JMeter.
- Comparez avec la partie 2 : le temps moyen fond, et le processeur de http20 respire. Expliquez pourquoi dans votre guide.
| secondes / serveur | HTTP | MYSQL | VARNISH | temps moyen de réponse (seconde) |
|---|---|---|---|---|
| 10 secondes | ||||
| 60 secondes |
Varnish
- (2 points) sa version de son guide d'installation
- (1 point) les fichiers de configurations utilisés
- (1 point) le tableau rempli
- (1 point) les captures d'écran
Un minimum de 2 commits pertinents doit être effectué en classe durant la semaine 2, les autres devant être complétés avant le cours de la semaine 3. Ce laboratoire doit être entièrement terminé pour le début de la semaine 3.
Livrables et devoir
- Dans Git : guide d'installation, fichiers de configuration (varnish.service, default.vcl, ports.conf), tableau, captures.
- Les trois instances restent fonctionnelles pour la suite.
- Devoir : terminer le laboratoire avant le cours de la semaine 7.
La semaine prochaine, l'acte 6 : les Guildes ouvrent - profils de membres et points calculés en temps réel, du contenu personnalisé que la cache ne peut pas servir. On sépare la base de données du web, chacun sa machine, et on mesure le gain.