Révision pour l’atelier « Web Caching » chez Xebia

1 - Introduction


Pour ceux qui n'ont pas pu aller à la première séance de l'atelier « Web Caching, mod_cache, Varnish, Amazon CloudFront CDN et S3 » organisée par Xebia, voilà de quoi réviser avant d'aller aux prochaines séances.

Nous n'aborderons que la théorie, car la pratique sera faite lors de l'atelier.

2 - Principe d'un cache Web

Le but d'un cache web est d'accélérer les temps de réponse et/ou réduire la charge serveur en conservant une copie de certaines ressources afin d'éviter certains traitements lourds.

En version très simplifiée, sans cache on aura cette cinématique.

Avec cache on aura.

 

3 - Détecter les ressources non cachées de votre site web

Afin de détecter les problèmes de gestion de cache, il existe plusieurs outils qui vont confronter votre site web aux bonnes pratiques établies par Yahoo, Google...

Parmi ces outils, on peut citer :

Leurs utilisations sont assez simples.

Par exemple, on obtiendra des recommandations de ce type avec YSlow.

La même chose avec Google PageSpeed.

 

4 - Correction des problèmes détectés

Une fois que les problèmes ont été détectés, il faut les corriger.

La solution qui sera traitée durant l'atelier est d'utiliser la directive Expires.
Cette directive permet de savoir si la ressource en cache est à jour.

Pour cela, on utilisera ExpiresFilter dans le fichier web.xml de votre site web.

Pour chaque type de ressource (image, text, javascript) il faudra ajouter une date d'expiration.

Par exemple.

    ...
 
       ExpiresFilter
       org.apache.catalina.filters.ExpiresFilter
 
          ExpiresByType image
          access plus 10 months
 
          ExpiresByType text/css
          access plus 10 months
 
          ExpiresByType application/javascript
          access plus 10 months
 
    ...
 
       ExpiresFilter
       /*
       REQUEST
 
    ...

Avec Spring PetClinic on aura.

Avant

Après


Comme on peut le voir, les ressources de notre site web sont maintenant bien cachées (elles n'apparaissent plus dans le diagnostic).
Plus d'informations sur le site de Tomcat.

5 - Service de stockage Clouds : Amazon S3

Lorsqu'on veut stocker des fichiers, il existe plusieurs solutions :

  • En blob en base de données
  • Directement sur un système de fichier
  • Sur un service de stockage comme Amazon S3

L'avantage d'Amazon S3 par rapport aux deux autres solutions est sa simplicité (pas de serveur à gérer, moins de contraintes sur la base de données, choix de la région géographique de stockage...).

Une fois mise en place on aura une architecture du type.

L'upload de fichier peut se faire de plusieurs façons :

  • Utilisation d'un client ftp
  • Utilisation du SDK afin d'intégrer les fonctionnalités d'Amazon S3

Pour informations, Xebia utilise cette technologie pour les vidéos disponibles sur leur blog.

6 - CDN

Le principe du CDN (Content Delivery Network) est d'héberger les ressources statiques de votre site web sur des serveurs situés sur toute la planète afin de réduire les latences réseau entre l'internaute et la ressource demandée.

De plus, cela déporte le traitement de ces ressources sur des serveurs externes à votre infrastructure et donc allège les ressources utilisées de vos serveurs.

Et par serveurs externes, il faut comprendre :

  • Des serveurs avec un débit réseau plus grand que les vôtres
  • Des serveurs en plus grand nombre
  • De la supervision 24h sur 24 et 7j sur 7
  • Des ressources humaines plus pointues pour l'optimisation des serveurs

Prenons comme exemple le cas suivant.
Notre site web est hébergé en France et des utilisateurs du monde entier y accèdent.

Pour la récupération des ressources statiques, on aura les flux suivants si aucun CDN n'est paramétré.

On voit bien que notre serveur doit traiter toutes les demandes concernant les ressources statiques et que les latences pourront être grandes.

Avec du CDN on aura.

Notre serveur est déchargé de l'envoi des ressources statiques (gain de bande passante et de CPU) et les latences seront réduites.

Pour nous aider, YSlow nous calcule le nombre d'éléments par hôte.

6.1 - JS et CSS CDN pour JQuery, Dojo, Bootstrap...

Le principe est d'utiliser des serveurs tiers qui hébergent un certain nombre de librairies JS et CSS que vous utilisez dans votre site web.

La mise en place est assez simple. Il suffit de modifier vos pages web afin d'utiliser les bonnes librairies.

Par exemple

 

Les avantages sont nombreux et on peut citer :

  • Peut régler le problème de nombre de téléchargement en parallèle sur un même hôte des navigateurs
  • Si l'utilisateur a déjà été sur un autre site Internet qui utilise la même librairie et le même CDN, la librairie sera déjà dans le cache du navigateur
  • Utilise le principe de CDN pour réduire les latences réseau
  • Ce ne sont plus les ressources de vos serveurs qui sont utilisées pour le transfert de ces ressources
  • Réduit le nombre de serveurs à gérer en interne.

Il existe plusieurs CDN comme :

6.2 - Amazon CloudFront CDN

Lors de l'atelier, Amazon CloudFront CDN sera utilisé pour cacher les ressources statiques, mais il en existe plusieurs avec des prix et des fonctionnalités différentes.

Par exemple Akamai et OVH.

7 - Proxy cache

Comme son nom l'indique, un proxy cache est un serveur proxy avec un cache.
Il peut être placé à différents endroits de l'architecture.

En frontal.

Entre deux serveurs (Serveur CMS + serveur Tomcat).

7.1 - Apache Httpd avec le module mod_cache

Un moyen simple de mettre en place un proxy cache sans ajout d'un nouvel outil est d'utiliser le module mode_cache d'Apache Httpd.

Les étapes pour y arriver sont les suivantes :

    • Activer le module mod_proxy en créant un fichier de configuration dans /etc/httpd/conf.d/

  • Activer le module mod_cache à l'aide du fichier de configuration /etc/httpd/conf/httpd.conf

 

7.2 - Varnish Caching Proxy

Comme pour les CDN, Varnish est un proxy cache utilisé par de nombreux grands du web (je vous laisse fouiller sur le site High Scalability pour trouver des noms).

L'intégration de Varnish est réalisée à l'aide de son langage de configuration nommé VCL afin d'interagir sur le cycle de vie d'une requête.
Pour chaque étape de ce cycle de vie, on dispose d'une fonction/intercepteur correspondant dans le VCL.

En particulier :

  • vcl_recv : déclenché lors de la première étape d'une requête entrante
  • vcl_fetch : déclenché lorsqu’une requête entrante sollicite un contenu non caché. La règle définie sera appliquée au retour de ce contenu.

Ces règles nous permettront d'ajouter dynamiquement des informations aux en-têtes des réponses HTTP.

L'utilisation de la directive backend (liste des serveurs que Varnish va pouvoir solliciter pour aller chercher le contenu) et passer en mode grace (fournir le contenu malgré que le backend soit hors service) seront abordée.

Une fois mise en place on aura l'architecture suivante.

 

8 - Conclusion

Je remercie Xebia et en particulier Julia Mateo, Cyrille Le Clerc, Seven Le Mesle, Charles Blonde et Stéphane Moreau pour l'atelier et vous conseille d'aller aux prochaines séances.

Laisser un commentaire

Merci d'effectuer cette opération simple pour valider le commentaire *

Mots-clés
RSS Feed