Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

eZHumanCAPTCHACode reload
retour

Le cache HTTP

Le cache HTTP

En grande majorité, les sites servent les mêmes pages à tout le monde, et en grande majorité, ces pages sont construites par un CMS ou une application dédiée, au moyen d’un gabarit, dans lequel sont insérés les contenus extraits d’une base de données. L’élaboration des pages est un travail important, qui consomme beaucoup de ressources, et peut prendre jusqu’à 0,1 seconde, voire 1 seconde. Mais puisque la page a déjà été construite quelques secondes plus tôt pour un autre internaute, inutile de tout recommencer, il suffit de l’avoir conservée en mémoire, prête à l’emploi.

C’est donc là le principe du cache HTTP, qui peut multiplier par 100, voire 1000, la capacité d’accueil d’une plateforme Internet, et il existe depuis longtemps d’excellents outils open source pour mettre en place un cache, ceci quel que soit le CMS, ou bien l’application en général, qui construit les pages.

Le gestionnaire de cache est placé devant le serveur HTTP, c’est lui qui reçoit les requêtes des internautes. Si la page demandée est dans son cache, il la sert directement, sinon, il la demande au serveur, puis la range dans son cache, pour un éventuel usage futur. Dans ce dispositif, chaque page peut comporter sa propre indication de durée de vie, durée pendant laquelle elle peut être servie à partir du cache, avant d’être rafraîchie.

Cache du navigateur

Nous l’avons évoqué déjà, les navigateurs web intègrent tous une gestion du cache sur les pages html et les composants qu’elles intègrent. Le protocole HTTP comporte différentes directives permettant de contrôler cette gestion du cache, et la bonne gestion de ces directives, souvent négligée, peut améliorer très sensiblement les performances d’un site.

 

image126

Le principe général est le même et repose également sur la bonne indication de durée de vie.
Pourquoi mettre en place un cache Html/HTTP côté serveur puisqu’on peut compter déjà sur un cache côté navigateurs ?
C’est très simple : le cache du navigateur ne peut servir que si un même internaute demande deux fois la même ressource. Un cache côté serveur est utile aussitôt que deux internautes différents demandent la même ressource. Et ce n’est pas tout : le cache côté serveur est parfaitement maîtrisable, configuré précisément pour nos besoins, tandis que le cache des navigateurs a une configuration que nous ne maîtrisons pas.
Comme représenté sur la figure ci-contre, le cache HTTP du côté serveur est partagé par tous les internautes, son efficacité potentielle est donc plus grande.

En revanche, le cache côté client soulage toute la plateforme, y compris sa bande passante et ses routeurs.

Un peu de mémoire suffit

Sur un site, il est courant que la home page représente jusqu’à 30% des accès, et une vingtaine de pages peut concentrer plus de 50% des accès, de sorte qu’un peu de mémoire suffit pour un cache efficace.

image128

La figure précédente représente l’évolution typique du hit-ratio, le taux de page servies à partir du cache, en fonction du pourcentage de pages que peut contenir le cache. Où l’on voit qu’avec 10% des pages en cache, on peut déjà espérer plus de 50% de succès.

La mémoire ne coûte pas cher

En fait la mémoire ne coûte pas cher aujourd’hui, et il est souvent possible de disposer de la totalité des contenus en mémoire.

.
Considérons un site qui comporte 10 000 pages, chaque page ayant un poids de 100 ko, pour la partie Html du moins. Ce sont des chiffres assez représentatifs d’un site plutôt haut de gamme. Est-il possible de mettre tout cela en cache ? 10 000 x 100 ko = 1 Go. Un giga-octet de mémoire, c’est très peu de chose aujourd’hui. Noter qu’on ne parle pas ici des images, qui ne seront guère plus volumineuses, et moins changeantes et sont donc particulièrement prédisposées à une bonne gestion de cache.

Lorsque tout peut tenir en mémoire, il n'est plus question de MRU, on garde tout. Ce qui limitera le hit ratio, malgré tout, c’est la durée de vie des contenus. Si elle est suffisamment longue, par exemple une journée, alors effectivement, chaque contenu ne sera produit qu’une seule fois par jour, puis servi uniquement depuis le cache. Mais si l’on considère que les contenus doivent être rafraîchis toutes les 10 minutes, alors il est possible que certains contenus ne soient jamais resservis depuis le cache.

En supposant la capacité du cache suffisante pour la totalité des contenus, on peut se livrer à un calcul simple, faisant intervenir deux paramètres : le nombre de pages servies par seconde et la durée de vie des pages.

Soit D, la durée de vie des pages en cache ; P, le nombre de pages servies par seconde à l’heure de pointe ; N le nombre total de pages.

Faisons l’hypothèse typique que 80% des requêtes portent sur 20% des pages.

Pour que le cache commence à être utile, il faut que sur la durée de vie D, on ait servi plus de pages que N x 0,2, les 20% de pages les plus utilisées.
C’est à dire :
P x D x 0,8 > N x 0,2
et donc :
D > (N x 0,2) / (P x 0,8)
ou encore :
D > N / 4P.
Attention, on calcule ici le seuil à partir duquel le cache commencerait à être utile. Ce n’est pas par cette formule qu’il faut calibrer la durée de vie en cache des contenus. Plus la durée de vie est importante, plus le bénéfice du cache est grand. En fait le réglage est d’ordre fonctionnel et non technique : quelle est la durée de validité d’un contenu, quelle est la réactivité requise en cas de changement ? C’est affaire de compromis entre efficacité du cache et réactivité face aux changements.

Application numérique typique : N = 10 000 pages, P = 10 pages par seconde : D = 3 minutes environ. 10 pages par seconde, c’est environ 40 000 visites par jour, c’est donc un site moyen en termes d’audience. Si l’on prend P = 50 pages par seconde, on est au niveau d’un site plus sérieux, à 200 kv/j, et le cache commence à être utile à partir de 0,5 minutes. Le calcul est simplifié, évidemment, car on pourrait s'intéresser aussi aux 10 pages qui représentent peut-être 20% du trafic total. Pour ces pages-ci, on trouverait D > 10 / (P x 0,2 ), c'est à dire que le cache serait utile encore plus tôt.

On en déduit plusieurs choses :

  • Plus l'audience est forte plus le bénéfice du cache est important, c'est assez évident.
  • Mais surtout: pour un site à forte audience, même un cache de courte durée de vie commence à être utile, c’est à dire que le bénéfice du cache n’est pas incompatible avec une haute fréquence de mise à jour.

Mise en œuvre d’un cache HTTP

Nous avons traité des différents aspects théorique du cache, voyons-en les aspects plus pratiques.

Le gestionnaire de cache (en mode pull), est une application, un outil, qui se place devant l’application web. Ce peut être sur le même serveur physique, ou bien sur un serveur physique (ou virtuel) dédié. Le gestionnaire de cache demande peu de ressources, si ce n’est de la mémoire, de sorte qu’il peut souvent être placé sur le même serveur que l’application web.

Pour une application web complexe, par exemple une gestion commerciale, ou bien un ERP, ou encore le back-office d’un outil CMS, le degré de variation des pages est en général trop important pour qu’il y ait beaucoup à gagner avec un gestionnaire de cache. Du moins pour les parties applicatives des pages, car on peut toujours gagner sur les composants auxiliaires tels que images, css ou bien javascript. Mais s’il ne s’agit que de ces composants, le cache natif du serveur Apache suffira en général. On veillera simplement à ce que ces composants soient servis directement par le serveur Apache, et non par le serveur d’application.

Dans beaucoup de cas, la mise en place du cache devant un CMS est pratiquement transparente, c’est à dire qu’on ne change rien du côté du CMS, et que l’on bénéficie immédiatement de performances décuplées. Pourquoi s’en priver ?

La transparence n’est pas toujours totale. La première adhérence réside dans la bonne gestion des durées de vie, et de durées de vie différenciées selon les composants, comme on l’a vu plus haut. Comme on l’a vu plus haut, la durée de vie d’une page (ou plus largement d’une « ressource ») est spécifiée par le producteur, dans l’entête HTTP. Or il est fréquent que les CMS ne laissent pas une maîtrise fine des paramètres de l’entête HTTP.

La seconde difficulté est la personnalisation des pages qui, comme on l’a dit, est de plus en plus importante sur les sites modernes. Ici deux approches sont pratiquées :

  • Soit une distinction globale entre pages génériques et pages personnalisées, les premières étant gérées en cache, et les secondes non.
  • Soit une gestion de cache par fragment mais qui présente l’inconvénient de ne pas être transparente.

Les outils du cache HTTP

L’outil de cache le plus célèbre est Squid, un serveur proxy utilisé le plus souvent en mode « reverse proxy » c’est à dire en tant que serveur de cache. Squid remonte aux débuts du web, avec une version 1 qui date de 1996. C’est un projet qui a peu évolué, pendant pas mal d’années, mais qui s’est réveillé depuis 2008.

Squid permet de configurer la quantité de mémoire allouée au cache ; elle est gérée en MRU, mais les objets évacués du cache sont écrits sur disque, d’où ils peuvent être réutilisés dans les limites de leur durée de vie. De plus lorsqu’on arrête un Squid, il écrit sur disque tous les objets qui étaient en mémoire, et qui seront rechargés lors de la relance, ce qui est important car le redémarrage avec un cache vide peut amener une très forte sollicitation initiale du serveur source.

La gestion des durées de vie est essentiellement dictée par les consignes des entêtes HTTP, c'est-à-dire par l’application source. C’est au niveau de la source que se fait la configuration, qui permet donc de distinguer différentes typologies d’objet, aux durées de vie différentes.

Notons que dans sa version 3, Squid annonce le support ESI, mais il est encore en rodage pour l’instant.

Varnish est un outil plus récent, également open source, qui cible directement la fonction de cache, et annonce des performances supérieures.

Un cache HTTP est souvent mis en œuvre seulement pour les objets média, ou composants relativement statiques : images, css, flash, etc. Dans cette configuration, sa mise en œuvre est réellement transparente. Il peut apporter beaucoup sur les pages elles-mêmes, mais à condition de bien maîtriser les durées de vie de côté de l’application.