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

Cache en mode push

Cache en mode push

Nous avons défini plus haut le principe du cache en mode push : c’est le producteur qui pousse les objets, les ressources, vers le cache.

A la différence du consommateur, le producteur, qui gère la version originale de l’information, sait quand l’information a changé. Ainsi à la manière des dispositifs de réplication des bases de données, on peut faire en sorte que ce soit l’événement de changement qui déclenche l’envoi de l’information aux différents caches. Cela suppose une forme d’inscription, d’abonnement, du cache auprès de la source de données. Et cela implique aussi une phase d’initialisation. Dans un cache en mode push, on suppose généralement que le cache possède une copie de l’ensemble des données et non un sous-ensemble particulier.

C’est ce que l’on peut représenter comme suit :

image134

On voit sur ce schéma que le point de départ du processus est cette fois-ci le serveur producteur de l’information, qui dépose, pousse, les objets sur le cache.

On peut aussi mettre en place des modes mixtes, où le producteur ne pousse pas la ressource vers le cache, mais déclenche son invalidation, de sorte qu’elle sera rafraîchie à la prochaine utilisation. C’est ce que permet Squid par exemple, avec un service d’invalidation, qui peut être appelé par simple invocation d’une URL.

Génération de pages statiques

La génération de pages statiques est un cas particulier du cache en mode push.

A l’origine du web, il y avait des fichiers html posés dans les répertoires d’un serveur. Le serveur HTTP a été initialement conçu pour analyser les requêtes des internautes et servir ces pages. On les a appelées pages statiques plus tard, par opposition aux pages dynamiques élaborées par des applications.

Aujourd’hui encore, rien n’est plus efficace que de servir des pages statiques. Le serveur Apache gère nativement un cache pour ce type de pages, et peut en servir plusieurs milliers à la seconde, pour autant qu’on lui donne la mémoire qu’il lui faut.

Les pages statiques, ce n’est pas juste plus rapide, c’est aussi plus fiable, bien sûr.

Mais le tout-statique a aussi beaucoup d’inconvénients, en particulier le manque de flexibilité, la difficulté à traiter chaque internaute de manière spécifique, et à gérer de l’information changeante. Et la difficulté à assurer une parfaite cohérence des liens en présence de déplacements ou renommages de rubriques, et à assurer une parfaite cohérence graphique.

C’est pourquoi le web est passé en mode dynamique. Avec un niveau de service très supérieur, mais aussi de moindres performances.

Ne peut-on pas avoir à la fois les hautes performances et l’aspect dynamique ?

Dans certains cas, on le peut. C’est le propre de la génération de pages statiques. Le principe est celui d’une génération de page dynamique, mais la page une fois générée est écrite sur disque en un fichier Html, et c’est ce fichier qui est servi par le serveur HTTP.

Beaucoup de sites ont un taux de changement très faible. Il s’écoule souvent plusieurs jours, voire une semaine entière sans le moindre changement. A quoi bon regénérer des pages toujours identiques ?

Bien sûr, les dispositifs de cache, déjà évoqués, répondent aussi à cette problématique : éviter de recalculer une page qui n’a pas changé. Et effectivement, génération statique et solution de cache ont la même finalité. Mais des atouts spécifiques.

Une solution de cache en mode pull, invoque son application moins souvent, mais l’invoque quand même régulièrement. Si l’application est en dysfonctionnement, l’impact est retardé, mais demeure.

Par rapport à un dispositif de cache, la génération de pages statiques permet de découpler bien plus fortement le système d’édition, le back-office, et le système de publication, le front-office. Cela permet de mettre en place des architectures dans lesquelles la plateforme de production est minimaliste et simplifiée au maximum. Servir des pages statiques est non seulement ultra-performant, mais aussi ultra-extensible.

Mais s’il y a plusieurs dizaines de milliers de pages, voire centaines de milliers, la regénération peut être un processus de plusieurs heures. La solution serait une regénération partielle, qui ne porterait que sur ce qui a changé. Mais l’analyse des impacts peut être un problème complexe. Certains petits changements peuvent impacter un très grand nombre de pages, voire toutes les pages ;

Il n’y a pas d’outil standard de génération statique, c’est à dire que c’est une technique encore assez artisanale, mais les bénéfices peuvent être énormes. Smile a été amené à mettre en place un principe de génération de pages statiques à partir d’un CMS à de nombreuses reprises. Citons les cas de la plateforme voyages-sncf.com, de Bouygues Telecom, ou encore de Sport24.com.

A la base de ces techniques, il y a un principe semblable à celui de l’ « aspiration » de site : un petit programme externe au CMS va demander une page, et la stocker sur le disque. La commande wget est généralement utilisée à cet effet. Il est possible de procéder vraiment comme un aspirateur de sites, c’est à dire de rechercher les liens dans la page obtenue, et de requêter ensuite les pages correspondant à ces liens. Mais c’est une technique trop grossière, qui ne permet pas de corréler la génération de page avec les changements effectifs, et oblige donc à tout regénérer périodiquement.

Pour ne regénérer que le minimum, et pouvoir donc opérer en quasi temps-réel, il faut d’une part déclencher l’export statique sur l’événement de changement d’un contenu et d’autre part bien identifier les impacts d’un changement.