Caches
Acte 5 · La cache qui absorbe tout : 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 · VarnishLa carte avant la route
| Cache | Il vit où ? | Il garde quoi ? | Il brille quand... |
|---|---|---|---|
| Varnish | Devant le serveur web (sa machine ou la même) | Des réponses HTTP complètes | ...la même page est demandée par tout le monde. |
| mod_cache | Dans Apache | Des réponses HTTP | ...on veut un cache HTTP sans machine de plus. |
| OPcache | Dans PHP | Le bytecode compilé des scripts | ...toujours : chaque page PHP en profite. |
| APCu | Dans PHP (local à la machine) | Des objets et variables | ...une seule machine web génère des pages personnalisées. |
| Memcached | Service en RAM (même ordinateur ou machine dédiée) | Objets, sessions, résultats de requêtes | ...plusieurs serveurs web partagent le même cache. |
Le cache HTTP court-circuite l'exécution; le cache d'exécution la rend moins chère. Un site occupé veut les deux.
Pourquoi recuisiner le même plat ?
L'encyclopédie et les fiches de règles deviennent virales : des centaines de milliers de lectures des mêmes pages fixes. À chaque visite, WordPress recalcule la même page - PHP s'exécute, MySQL répond, Apache assemble - pour servir un résultat identique à celui d'il y a deux secondes. Cent mille lectures, cent 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