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 par fragments

Cache par fragments

Sites personnalisés et contenus temps-réel

Un bon outil de cache peut servir quelques milliers de pages à la seconde, sur un unique serveur. Et ce n’est pas tout : le cache contribue aussi à la haute disponibilité puisque si l’application ne répond pas, le cache peut toujours fournir une page, peut être un peu ancienne, mais c’est mieux que rien.

Tout cela est magique, du moins tant que l’on sert les mêmes pages à tout le monde, au moins pour quelques temps. C’est le cas de beaucoup de sites, mais depuis quelques années déjà, on observe une tendance puissante vers la personnalisation des sites : chaque internaute est

identifié, et reçoit une page spéciale, dépendant de ses préférences et options.

Si chacun reçoit une page unique, c’en est fini du cache et de ses milliers de pages par seconde. Faut-il en rester là ? Soit renoncer à des sites personnalisés, soit empiler une trentaine de serveurs pour tenir la charge ?

Non, heureusement, il nous reste quelques armes.

Introduction au cache par fragments

A bien y regarder, même si chaque page est unique, de nombreux morceaux de la page sont les mêmes pour différents internautes. A défaut de mettre la page entière en cache, on peut donc tenter de mettre des morceaux de pages en cache, des fragments. Typiquement, beaucoup d’éléments de navigation, mais aussi des blocs entiers de contenus, seront intégrés à l’identique dans les pages de tels et tels internautes, même si c’est éventuellement à des emplacements différents.

Cette réflexion amène à la notion de cache par fragments : on ne gère plus en cache des pages web entières mais des fragments de pages. Et le principe est que chaque fragment peut avoir une durée de vie particulière : des parties fixes de la page, un empied par exemple, ne seront rafraîchies que toutes les 4 heures, tandis que des actualités récentes seront rafraîchies tous les ¼ d’heure, et certains fragments, eux, ne seront pas du tout mis en cache, ils seront systématiquement demandés au serveur.

image130

La figure précédente compare le cache de pages, à gauche, et le cache de fragments, à droite. Le cache de fragments implique une phase d’assemblage, d’agrégation, en aval du cache. Mais il permet de produire une variété de pages à partir d’un ensemble de blocs, de fragments, qui ont des durées de vies variées.

Agrégation de fragments et portails J2EE

La gestion d’un cache par fragment combine donc deux fonctions distinctes : la fonction d’agrégation et la fonction de cache. La fonction d’agrégation consiste à produire une page à partir de différents fragments.

C’est une fonction qui correspond à un besoin usuel, indépendamment de la problématique du cache, puisque c’est la fonction principale des outils de portail, des outils tels que Jetspeed, Liferay, Uportal, ou encore Websphere Application Portal. Ce sont les portails du monde J2EE, les portails répondant à la norme JSR168-JSR286. Cette norme définit des APIs entre le portail agrégateur et les applications fournissant les contenus agrégés. Ces APIs sont définies en Java, et donc ne conviennent que pour cet environnement, elles ne sont pas technologiquement neutres.

C’est là une limitation intrinsèque des portails J2EE : ils sont faits pour agréger des contenus fournis par des applications Java. Et ce n’est pas tout : des applications Java écrites pour supporter les APIs du portail. C’est beaucoup demander et dans la pratique, le besoin est très souvent d’agréger des contenus issus d’applications d’une part hétérogènes, d’autre part pré-existantes, et pas uniquement Java. En d’autres mots : il faut prendre les applications comme elles sont.

Or la fonction du cache agrégateur de fragments reprend, pour partie, cette mission d’agrégation du portail, de manière à la fois plus simple et technologiquement neutre.

Edge Side Include (ESI)

Akamai a défini le Edge Side Include (ESI), devenu une norme du W3C, et adopté par quelques autres grands acteurs. ESI permet d’inclure dans une page web des fragments html obtenus en HTTP, en interrogeant différents serveurs. Pour spécifier cela, on inclut dans la page principale des tags de la forme

<esi:include src= "HTTP://www.mysite.com/fragment01" />

Cette balise signifie qu’à cet endroit de la page doit être inséré le fragment obtenu à l’adresse indiquée. Il appartient alors au dispositif ESI d’aller chercher cette ressource à l’adresse HTTP indiquée, et de l’insérer à l’endroit du tag <esi/>.

Un point important est que pour le fournisseur de la ressource, aucune interface spécifique n’est requise, il s’agit simplement de servir un morceau de html sur le protocole HTTP.

Dans un système de cache par fragment, le gestionnaire de cache est donc en charge d’élaborer la page, en insérant tous les fragments à la position appropriée. Lorsque tous les fragments sont en cache, c’est immédiat, et cela ne requiert aucun accès au serveur HTTP. Si un fragment n’est pas dans le cache, ou bien si la version en cache est périmée, trop ancienne, alors ce fragment seulement est obtenu auprès du serveur.

Un tel dispositif de cache par fragments permet donc de faire cohabiter dans les pages, des parties stables et des parties dynamiques, des parties identiques pour tous et des parties personnalisées, chacune bénéficiant d’un cache conforme à son besoin.

L’un des inconvénients du cache par fragment, qu’il s’appuie sur ESI ou non, est qu’il n’est pas transparent pour les applications. La structure même de l’application est impactée : au lieu de servir des pages, elle doit servir des fragments. Ce n’est pas anodin car toutes les applications, tous les outils de développement, sont conçus pour élaborer des pages web. A commencer par les outils de gestion de contenus, qui sont derrière la plupart des sites.

Web-scraping, web-clipping

Un cache ESI est donc un bel outil, mais il implique en général de recevoir des fragments élaborés spécifiquement à cet usage. Dans certains cas, on souhaite plutôt manipuler des fragments directement récupérés d’applications existantes, c’est à dire des morceaux extraits de pages entières, typiquement un bloc <div/> au sein de la page.

La technique que l’on appelle web scraping, ou web-clipping, consiste à récolter des données au sein de pages html. On peut pratiquer le web scraping avec une participation de l’application producteur, ou bien à son insu. Lorsque l’on maîtrise l’application qui produit la page, alors on pourra soit lui demander de fournir ses contenus d’une manière plus structurée que sur du simple Html (par exemple une interface de type REST/XML), ou bien lui demander plus simplement encore de placer des balises particulières au sein du Html, qui permettront au consommateur de repérer à coup sûr la partie utile. Lorsqu’on ne maîtrise pas l’application producteur, alors on ne peut qu’essayer de se repérer par rapport aux balises du Html, typiquement rechercher un « div » particulier, puis prendre le second tableau, la troisième ligne, etc. C’est cela qu’on appelle le plus souvent web scraping, et l’on voit bien que c’est une technique assez fragile, car le moindre changement de montage html casser l’identification des fragments.

Caches ESI Open Source

Malheureusement, il n’existe pas d’outil open source solide pour la gestion d’un cache ESI. C’est une fonctionnalité prévue de longue date dans Squid v3, mais Squid v3 n’est pas « production ready » à ce jour, selon l’aveu même de ses développeurs : « la plupart des bugs restant de Squid v3 concernent le ESI ».

Varnish en est à peu près au même stade, avec une implémentation d’un sous-ensemble de la norme ESI, mais ici aussi, l’avertissement est « attendez-vous à des bugs » !

Notons que l’on peut obtenir un service d’agrégation semblable en utilisant le module Server Side Include (SSI), de Apache, mais il faut encore y ajouter une gestion de cache ordinaire par Squid.

Le Web Assembling Toolkit

Pour d’autres types de projets, Smile a mis au point le Web Assembling Toolkit (WAT). Il s’agit d’un ensemble de taglib JSP, qui permettent de constituer des pages en insérant du contenu obtenu en HTTP à partir d’autres serveurs. Et même si l’agrégation est sa mission première, WAT gère aussi un cache, sur chacun des fragments ainsi obtenus.

Comme on l’a vu, la clé de la haute performance c’est de réunir cache et agrégation. WAT combine ainsi les deux rôles : outil d’agrégation, et outil de cache par fragments.

Un fonctionnement général que l’on peut représenter comme suit :

image132

Et WAT a une autre caractéristique : lorsqu’il appelle un serveur pour obtenir un fragment, il est capable d’extraire un petit morceau de la page obtenu. C’est du web-clipping : on obtient une page, et on découpe le morceau qui nous intéresse, qui constituera le fragment. Cette technique permet en particulier d’obtenir des fragments à partir d’applications existantes, qui n’auraient pas été conçues spécifiquement pour être agrégées ainsi au sein d’un portail. Pour certains, le web-clipping est une solution un peu rustique, du bricolage presque. Ne vaudrait-il pas mieux invoquer un superbe web-service ? C’est discutable. Le bénéfice essentiel du web-clipping est le caractère non-structurant : il ne demande rien de particulier aux applications intégrées.

Placé en frontal des applications, WAT joue en quelque sorte le rôle d’un portail. Mais dans certains cas, il est en fait combiné à un véritable portail, par exemple Jahia. C’est le cas du nouveau site d’assurance idmacif.com, de la Macif, ou du portail de Bouygues Immobilier.

WAT est également utilisé par Editions Francis Lefebvre, Bluestar Silicones, La Poste, et le Conseil Supérieur du Notariat. C’est un projet open source sous licence Apache . Et depuis debut 2009, WAT supporte les tags ESI les plus importants.

Agrégation de fragments côté client

Si l’on parle d’agrégation de fragments, il est important de citer aussi la pratique d’une agrégation « côté client », c’est à dire sur le navigateur de l’internaute.

Il existe différentes techniques pour cela : iframes, inclusion de javascript générant des fragments Html au sein de la page, et enfin véritable Ajax.

L’agrégation côté client a de multiples avantages :

  • Elle permet d’agréger des contenus venant de différents serveurs
  • Le traitement ne demande aucun outil spécifique côté serveur
  • Le traitement ne consomme aucune ressource côté serveur

C’est en particulier une excellente technique lorsqu’un site produit des pages partiellement personnalisées. Typiquement avec un bloc personnalisé de type « mon profil », « mes préférences », etc. Dans ce cas, on peut bénéficier pleinement de la gestion de cache serveur (et client), en ne traitant de manière dynamique que le bloc considéré.