Table des matières de l'article :
Introduction : Un cache qui, en apparence seulement, « ne fonctionne pas »
La demande de conseils est arrivée comme c'est souvent le cas dans notre secteur : une discussion entre ingénieurs système, déclenchée par un problème qui semblait déjà établi.
Un site e-commerce WooCommerce, un trafic croissant, des performances fluctuantes et une conviction désormais profondément ancrée : Le vernis ne cacha.
Le responsable de l'infrastructure avait déjà effectué plusieurs vérifications superficielles. Les en-têtes HTTP indiquaient de fréquentes erreurs de cache, l'en-tête Age Elle restait constamment à zéro, et l'impression générale était que le proxy inverse n'apportait aucun avantage réel. D'où l'idée que le problème venait de l'outil lui-même.
Notre intervention n'avait pas pour but de « réfuter » qui que ce soit, mais de faire ce que nous avons toujours considéré comme essentiel : observer le système dans son ensemble, en partant des données et non des impressions.
La véritable pile technologique : une architecture correcte, des attentes erronées
L'une des premières choses que nous avons clarifiées concernait la pile qui était réellement utilisée, car il y avait également une certaine confusion sur ce point.
L'architecture était la suivante :
- NGINX comme terminateur HTTPS, publiquement exposé
- NGINX proxy inverse vers Varnish
- Varnish comme cache HTTP
- Varnish en proxy inverse vers NGINX
- NGINX connecté à PHP-FPM
- MariaDB en tant que base de données
Il s'agit d'une architecture tout à fait classique, que nous utilisons également dans de nombreux contextes de production. Rien d'expérimental, rien de fondamentalement mauvais.
C’est précisément pour cette raison que l’idée selon laquelle « le vernis ne fonctionne pas » dans un tel scénario méritait une analyse plus approfondie.
Contexte de l'application : WooCommerce et personnalisations importantes
Le commerce électronique qui faisait l'objet de la mission de conseil comprenait environ produits 10.000Un catalogue important, mais pas exceptionnel. Il faut dire que la base technologique était correcte : l’utilisation du vernis représente le étalon d'or Un choix incontesté pour toute architecture WooCommerce exigeant des performances et une stabilité élevées sous forte charge. Il n'existe actuellement aucun accélérateur HTTP plus efficace pour gérer la nature dynamique de WordPress à fort trafic.
Le thème, cependant, était fortement personnalisé et avait subi de nombreuses modifications au fil du temps, notamment au niveau de l'interface utilisateur, ce qui avait fini par annuler les avantages de cette architecture. Avant même d'aborder la question de la mise en cache, il était clair que la charge n'était pas tant due au nombre de produits qu'à la manière dont les pages étaient générées. En particulier, la structure HTML était anormalement lourde.
Comme toujours, nous avons décidé de commencer par une mesure objective.
Premiers tests : analyse du code HTML sans filtres
Nous avons effectué des requêtes directes vers les pages produits via curlNous avons délibérément évité toute négociation de compression (comme gzip ou Brotli) ou autre optimisation de transport. L'objectif n'était pas de simuler l'expérience utilisateur, mais d'isoler et de quantifier le « poids mort » du code HTML généré par l'application.
Le résultat fut immédiat et sans équivoque : Environ 1,3 Mo de code HTML brut par page produit.
Cette valeur constitue déjà en soi une anomalie. Mais elle devient un problème critique lorsqu'on l'analyse dans l'architecture d'un cache haute performance tel que… Vernis.
Pourquoi 1,3 Mo est fatal pour Varnish
Contrairement aux systèmes de stockage clé-valeur comme Redis — qui peut être configuré pour optimiser la densité des données ou gérer les structures compressées — Varnish fonctionne selon une philosophie architecturale totalement différente, basée sur vitesse d'E/S pure.
-
Aucune compression de la RAM : Varnish ne compresse pas nativement les objets en mémoire pour économiser de l'espace (allocation). mallocSon objectif est de récupérer le contenu et de le renvoyer sur le réseau en consommant le moins de cycles CPU possible. Économiser 1,3 Mo signifie occuper exactement 1,3 Mo de RAM pour chaque changement de page.
-
Latence et accès à la mémoire : Le vernis est conçu pour résister aux intempéries. des centaines de milliers de connexions simultanéesDans ce scénario, l'accès direct à la mémoire (RAM) doit être instantané.
-
Le déplacement de blocs de mémoire de 1,3 Mo exerce une pression énorme sur le bus mémoire.
-
Pour tenir la promesse d'un Temps d'accès au premier octet (TTFB) inférieur à une millisecondeLes objets doivent être minces.
-
En résumé : fournir à Varnish 1,3 Mo de pages revient à transformer une Ferrari en bus surchargé ; le moteur est puissant, mais la masse qu’il doit déplacer l’empêche d’atteindre les performances pour lesquelles il a été conçu.
Précision importante : les images étaient déjà exclues du cache
Au cours de la discussion, il était important de clarifier immédiatement un point : Les images n'étaient pas le problème..
Conformément aux bonnes pratiques, les images n'ont pas été mises en cache par Varnish, mais servies directement comme ressources statiques par NGINX, bénéficiant éventuellement de la mise en cache du navigateur ou de systèmes externes.
Cela signifie que le poids observé n'était pas dû au format JPEG, PNG ou WebP, mais exclusivement au balisage HTML.
Il ne s'agit pas là d'un détail secondaire, car nous avons souvent tendance à imputer aux images un problème qui découle en réalité de choix structurels totalement différents.
CSS en ligne et composants répétitifs : quand le HTML explose
L'analyse de la source des pages a révélé qu'une part importante de leur poids était due à :
- grands blocs de CSS en ligne
- Des menus complexes et des structures de navigation sont injectés directement dans le HTML.
- composants identiques et répétitifs sur chaque page produit
Tout contenu qui, d'un point de vue architectural, devrait être externalisé et réutilisé, et non dupliqué des milliers de fois dans le balisage.
Ce choix a un impact direct sur tout système de mise en cache : chaque URL produit un objet volumineux et unique qui occupe une précieuse mémoire.
Faites le calcul : le cache n’est pas magique.
À ce stade de la mission de conseil, nous arrivons à une étape simple, mais souvent négligée : s’arrêter et effectuer quelques calculs. Pas de critères complexes, pas d’outils sophistiqués, juste un calcul de base qui nous permette immédiatement de bien cerner le problème.
Si une seule page produit pèse environ 1,3 Mo de code HTML et que le catalogue contient approximativement 10 000 produits, le volume théorique de code HTML potentiellement mis en cache dépasse 13 Go. Il s'agit bien sûr d'un calcul purement théorique, mais il est extrêmement utile pour appréhender l'échelle du système que vous utilisez.
Cela ne signifie pas que toutes les pages doivent ou peuvent être mises en cache simultanément. Les schémas de trafic réels sont de plus en plus complexes : certaines pages sont très fréquemment consultées, d’autres rarement, et d’autres encore presque jamais. Toutefois, ce nombre constitue un indicateur essentiel pour déterminer si les ressources mises à disposition sont au moins compatibles avec la charge potentielle.
Dans ce contexte, la configuration de Varnish allouait environ 4 Go de RAM au cache. Hors contexte, cette quantité pourrait même paraître suffisante. Mais replacée dans ce contexte, il devient évident qu'elle ne peut pas contenir une part importante des données mises en cache, surtout si les objets sont volumineux.
C’est là que s’effondre l’un des mythes les plus répandus : Le cache n'est pas magique. Il ne résout pas automatiquement les problèmes structurels des applications, n'optimise pas automatiquement les contenus trop volumineux et ne peut pas contourner les limitations physiques des ressources disponibles. Son fonctionnement s'inscrit dans des limites bien définies ; si ces limites sont dépassées, son comportement reste correct, mais ses avantages sont considérablement réduits.
À partir de ce moment, le comportement observé (défauts fréquents d'accès au cache, augmentation rare de l'en-tête Age, gains marginaux) devient parfaitement cohérent. Il ne s'agit pas du symptôme d'une mauvaise configuration ou d'un dysfonctionnement, mais de la conséquence directe d'un déséquilibre entre la taille des objets, la quantité de contenu et la mémoire allouée.
Et c’est précisément à ce moment-là que le problème cesse d’être un « vernis qui ne fonctionne pas » et devient ce qu’il est réellement : un problème de proportions.
Que se passe-t-il lorsque Varnish manque de mémoire ?
Lorsque le cache Varnish atteint la limite de mémoire disponible, le processus ne plante pas et ne se bloque pas. Varnish est conçu pour fonctionner sous forte charge et gérer automatiquement la saturation du cache. Dans ce cas, c'est son mécanisme d'éviction des objets qui entre en jeu.
En interne, Varnish maintient une structure de gestion des objets mis en cache basée sur des métadonnées qui incluent la taille, la date de création, la durée de vie (TTL), le délai de grâce et le taux d'accès. Lorsque la mémoire allouée au cache est pleine, Varnish doit libérer de l'espace pour accepter de nouveaux objets. Pour ce faire, il applique ses propres politiques d'éviction, qui priorisent la suppression des objets les moins utiles selon des critères établis.
En pratique, les objets les plus anciens ou les moins utilisés sont déplacés pour faire place aux nouveaux. Ce comportement est normal et attendu, mais il prend un tout autre sens lorsque la taille moyenne des objets est très importante.
Dans un scénario comme celui que nous avons analysé, chaque objet HTML occupe une quantité importante de mémoire. Par conséquent, quelques nouvelles requêtes suffisent à déclencher un cycle d'éviction continu. Un nouvel objet entre dans le cache, mais pour ce faire, il doit en « déloger » un ou plusieurs objets existants. Il en résulte un cache extrêmement instable, dont le contenu change constamment.
D'un point de vue opérationnel, cela conduit à un comportement bien défini :
- Les objets sont initialement mis en cache
- La pression sur la mémoire augmente rapidement
- Les objets nouvellement mis en cache sont supprimés après quelques requêtes.
- Les nouvelles requêtes trouvent le cache vide ou partiellement vide.
Ce cycle se répète constamment, entraînant un flux constant d'échecs, non pas parce que Varnish ne met pas en cache, mais parce qu'il ne peut pas conserver les éléments suffisamment longtemps pour les rendre utiles.
Il est important de comprendre que, dans ces conditions, Varnish travaille plus que nécessaire. Chaque objet est toujours évalué, stocké temporairement, indexé, puis supprimé. Cela engendre une surcharge supplémentaire, sans pour autant améliorer concrètement le taux de succès.
Du point de vue d'un observateur extérieur du système, se limitant peut-être aux en-têtes HTTP, le résultat est trompeur. Vous constatez des réponses MISS, un en-tête Age qui dépasse rarement quelques secondes, et l'impression que le cache « ne rattrape jamais son retard ». En réalité, le cache fonctionne correctement, mais dans des conditions qui annulent son efficacité.
C’est là qu’un point essentiel apparaît : un cache n’est pas utile simplement parce qu’il existe, mais parce qu’il peut stabiliser la charge. Lorsque la mémoire est insuffisante par rapport à la taille et à la quantité des objets pouvant être mis en cache, cette stabilité est compromise. Le cache devient alors un système de transit temporaire, plutôt qu’une véritable couche d’accélération.
Comprendre ce fonctionnement interne est essentiel pour éviter tout diagnostic erroné. Le problème ne réside pas dans l'algorithme de Varnish, ni dans sa configuration intrinsèquement « mauvaise », mais dans le contexte de son implémentation. Sans une mise à l'échelle cohérente, même le meilleur algorithme de mise en cache est voué à produire des résultats décevants.
Le problème ne venait pas de la pile, mais de son dimensionnement.
L'un des aspects les plus intéressants qui est ressorti de la mission de conseil a été le critère de dimensionnement du VPS.
La machine a été choisie principalement sur la base de espace disque, probablement pour héberger les médias et les bases de données, tandis que la RAM était considérée comme une ressource secondaire.
Cette approche peut fonctionner sur un hébergement traditionnel, mais elle devient cruciale lors de l'introduction d'un cache HTTP en RAM.
Avec Varnish intégré, la mémoire devient une ressource centrale, et non plus une ressource auxiliaire.
Dans ce cas précis, la RAM allouée n'était cohérente ni avec la taille des pages ni avec le nombre d'URL concernées.
Solutions possibles : application ou infrastructure
Une fois les causes clarifiées, la consultation s'est orientée vers les solutions possibles.
Il y avait essentiellement deux options.
Intervenir dans la demande
La solution la plus appropriée d'un point de vue architectural comprenait :
- Réduction drastique du CSS en ligne
- externalisation des styles communs
- simplification des menus et des éléments répétitifs
- alléger le HTML global
Avec des pages plus légères, la même quantité de RAM pourrait contenir beaucoup plus d'objets, rendant le cache stable et efficace.
Adapter l'infrastructure
L'alternative consistait à intervenir sur l'infrastructure :
- augmenter significativement la RAM dédiée à Varnish
- ou configurez un cache disque pour étendre la capacité globale
Cette dernière option n'offre pas les mêmes performances que la RAM, mais elle permet à Varnish de continuer à fonctionner de manière constante même avec de très grands ensembles de données.
Cache disque : non pas un raccourci, mais un compromis
Lors de notre mission de conseil, nous avons pris le temps d'éclaircir un point souvent mal compris, notamment lorsque les ressources d'infrastructure sont limitées : l'utilisation du stockage disque pour la mise en cache n'est ni un échec, ni une solution de repli mal conçue. Il s'agit au contraire d'un choix délibéré, fruit d'une analyse des contraintes réelles du projet.
La mémoire cache RAM reste, par définition, la solution idéale en termes de latence et de performances. Cependant, il n'est pas toujours possible, ni économiquement judicieux, d'allouer suffisamment de mémoire pour stocker l'intégralité des données mises en cache, notamment lorsque les pages HTML sont très volumineuses ou lorsque le nombre d'URL augmente rapidement. Dans ces cas, l'extension du cache sur disque permet à Varnish de fonctionner de manière constante, évitant ainsi un cycle incessant d'insertions et de suppressions qui rendrait le cache inefficace.
Bien sûr, il s'agit d'un compromis : le stockage persistant ne peut égaler les performances de la RAM et induit une latence plus élevée. Mais ce compromis doit être considéré dans son ensemble, en tenant compte du type de charge de travail, de la fréquence d'accès aux pages et des performances attendues. L'erreur ne consiste pas à utiliser le disque pour la mise en cache, mais à le faire sans être conscient des conséquences.
L'essentiel est d'adapter les attentes à la réalité technique. Avec un stockage persistant, les performances ne seront pas les mêmes qu'avec une mémoire vive. En revanche, vous bénéficierez d'une meilleure stabilité, d'une plus grande prévisibilité et d'une amélioration tangible par rapport à un cache qui, bien que situé en RAM, est constamment sollicité.
La véritable valeur du conseil technique
Le moment le plus significatif de cette expérience n'a pas tant été l'identification du problème, mais le changement de perspective qui s'est produit au cours de la discussion.
Au départ, la discussion s'est articulée autour d'un constat clair : un outil qui « ne fonctionne pas ». Cependant, au fur et à mesure que l'analyse progressait, l'attention s'est progressivement déplacée des symptômes aux causes.
Une fois les chiffres concrets – la taille réelle des pages, la consommation de mémoire et le fonctionnement interne de Varnish – exposés, la conversation a changé de ton. Elle est enfin devenue une discussion technique, fondée sur des données objectives et non sur des perceptions ou des attentes déçues.
Il ne s'agissait plus de savoir si « le vernis ne fonctionnait pas », mais d'éléments concrets et mesurables :
- le poids du code HTML généré par l'application
- l'impact de ce poids sur le cache RAM
- les choix de développement qui avaient conduit à cette structure
- la relation entre l'application, le proxy inverse et les ressources disponibles
Et c’est précisément à ce stade que le conseil apporte une réelle valeur ajoutée. Non pas en imposant des solutions, mais en fournissant les outils nécessaires à la compréhension du problème. Non pas en remplaçant ceux qui gèrent le système, mais en les aidant à en interpréter le fonctionnement.
Lorsque le débat passe des jugements aux indicateurs, des opinions aux chiffres, les décisions gagnent en solidité. C’est alors que nous pouvons choisir en toute connaissance de cause d’intervenir sur l’application, l’infrastructure, ou les deux, en sachant précisément quels compromis nous faisons.
Conclusion : d’abord les chiffres, ensuite les décisions
Changer de technologie est souvent la solution de facilité. C'est une réaction compréhensible : lorsqu'un système ne fonctionne pas comme prévu, la tentation de le remplacer par une alternative « plus moderne », « plus simple » ou tout simplement différente est forte. Cependant, dans la grande majorité des cas, ce choix ne résout pas le problème de fond. Il ne fait que le déplacer.
Dans le domaine des systèmes et des infrastructures, les outils ne fonctionnent pas isolément. Tout logiciel, et notamment ceux conçus pour des performances élevées comme Varnish, ne révèle tout son potentiel que s'il est intégré à un contexte cohérent, conçu avec expertise et dimensionné en fonction de données réelles. Sans ces fondements, même la meilleure technologie risque de paraître inefficace.
Avant de remplacer un appareil, il est essentiel de comprendre son fonctionnement interne, ses limitations structurelles et les conditions dans lesquelles il a été conçu pour fonctionner. Dans ce cas précis, le comportement observé n'était pas le symptôme d'un dysfonctionnement, mais bien la conséquence directe d'une série de choix d'applications et d'infrastructures qui, combinés, avaient rendu le cache extrêmement instable.
Lors de cette consultation, nous n'avons pas défendu Varnish par préjugé, ni prétendu qu'il s'agissait de la seule solution possible. Nous avons simplement procédé comme nous l'estimons essentiel à toute analyse technique : en commençant par les chiffres. Taille réelle des pages, nombre d'objets mis en cache, mémoire disponible et comportement du système en charge. Tous ces éléments sont mesurables, vérifiables et objectifs.
Et c'est précisément lorsque les chiffres entrent en jeu que nombre de croyances commencent à s'effriter. Un système de cache qui semble dysfonctionner fonctionne souvent tout simplement dans des conditions pour lesquelles il n'a pas été conçu. Un proxy inverse qui renvoie de nombreuses erreurs (MISSES) n'est pas nécessairement mal configuré : Il se peut tout simplement qu'il soit surchargé d'objets trop volumineux pour les ressources disponibles.
Cette expérience nous a rappelé, une fois de plus, combien il est dangereux de raisonner en termes de slogans technologiques. « Cette pile technologique est meilleure », « ce logiciel est plus rapide », « ce système gère mieux le cache ». Sans contexte, sans chiffres et sans vision d'ensemble, ces affirmations sont dénuées de toute valeur technique réelle.
Les optimisations réellement efficaces, celles qui perdurent et évoluent avec le projet, reposent toujours sur une compréhension approfondie du système. Il s'agit de trouver le juste équilibre entre l'application, l'infrastructure et la charge réelle. Non pas d'apporter une nouvelle modification à la pile technologique, mais de savoir interpréter les signaux que le système envoie déjà.
Et c’est précisément dans cet espace — entre les chiffres et les décisions — que le conseil technique peut faire la différence.
