La cache
qui absorbe tout
Acte 6 : Varnish s'installe en avant du web et absorbe les demandes répétées avant qu'elles ne coûtent quoi que ce soit.
420-5A4-MT · Module 2 · VarnishPourquoi recuisiner le même plat ?
La séparation a soulagé les machines, mais un gaspillage saute aux yeux : à chaque visite, WordPress recalcule la même page d'accueil - PHP s'exécute, MySQL répond, Apache assemble - pour servir un résultat identique à celui d'il y a deux secondes. Dix mille visiteurs, dix mille cuissons du même plat. L'entreprise engage un serveur dont le seul métier est de garder les plats chauds : une cache.
- Objectif du jour : comprendre le cache HTTP et l'architecture Varnish.
Le cache HTTP
Une cache garde en mémoire les réponses déjà servies, pour les redonner instantanément sans refaire le travail.
La page demandée est déjà dans la cache : réponse immédiate, zéro travail pour le web et la base. C'est le but.
La page n'y est pas (ou est périmée) : la cache la demande au serveur web, la sert, et la garde pour les suivants.
Chaque entrée expire après un délai (TTL) : l'équilibre entre fraîcheur du contenu et travail épargné.
Varnish, l'accélérateur HTTP
Varnish est une cache HTTP professionnelle qui se place EN AVANT du serveur web. Les visiteurs parlent à Varnish; Varnish ne parle à Apache que lorsqu'il le faut.
- Varnish écoute sur le port 80 : c'est LUI la nouvelle porte d'entrée.
- Apache devient un backend : un fournisseur interne que les visiteurs ne voient plus jamais directement.
- WordPress doit connaître sa nouvelle adresse publique : l'URL du site devient l'adresse de Varnish.
Les deux fichiers qui font tout
Et de son côté, Apache cesse d'écouter sur toutes les adresses : il se replie sur la sienne (ports.conf et VirtualHost). Chaque serveur sa porte, chaque porte son rôle.
Observer sa cache
Le rapport hits sur miss est le bulletin de santé de la cache : un site vitrine bien mis en cache dépasse facilement 90 % de hits.
Tout ne se met pas en cache
- La page d'accueil, les articles, les images : identiques pour tous, parfaits pour la cache.
- Le panneau wp-admin, la connexion, le panier d'un client : personnels et changeants. Les mettre en cache, c'est servir la session de quelqu'un d'autre.
- La règle : le contenu public se cache, le contenu personnel passe tout droit. La semaine prochaine, HAproxy donnera même à l'admin son chemin réservé.
Avant de passer au laboratoire
- La cache sert les réponses déjà cuisinées : hit = gratuit, miss = on cuisine une fois pour tous les suivants.
- Varnish devient la porte d'entrée (port 80); Apache devient un backend invisible.
- varnishstat dit le rendement; le contenu personnel ne se met jamais en cache.
Au laboratoire : varnish30 s'installe en avant de http20, WordPress apprend sa nouvelle adresse, et le test de charge de la partie 3 devrait faire fondre le temps moyen de réponse. Les chiffres le diront.
Version de départ · ce diaporama va s'enrichir