Booster le chargement via Varnish

Actualisé le 22 avril 2014 - , ,

Pour ceux qui s’intéresse à l’optimisation de site voici un système de cache qui peut vraiment tout changer : Varnish.

Varnish agit comme un proxy intermédiaire entre le client et le serveur (reverse proxy), ce qui permet d’atteindre des performances vraiment importantes. Concrètement la sortie html de vos pages sera cachée lors des premières connexions puis sera servie pour les utilisateurs suivant depuis le cache. Il existe bien sur beaucoup de possibilités de configurations différentes, c’est pourquoi il important de bien le penser à l’avance.

Comment fonctionne Varnish (dans les grandes lignes) ?

Varnish comme dit précédemment s’interpose entre le visiteur (alias le client) et votre serveur. Il faudra bien configurer Varnish pour qu’il serve un contenu adéquat à chaque client. Admettons si vous avez une version mobile et desktop (pas responsive) de votre site, sans configuration adéquate, Varnish servira la première version qu’il a mis en cache lors de la visite du premier utilisateur, que vous soyez sur mobile ou desktop.

Donc par exemple, vous pourrez dans le fichier de configuration de Varnish différencier le cache si l’on est sur mobile ou desktop (avec une détection du user-agent). Autre cas, vous pourrez lui dire de ne pas mettre en cache les requêtes avec une entête POST afin de permettre la soumission de formulaire (du moins l’exécution du code de réception). Idem pour tous les autres types d’entête selon vos besoins.

A savoir également que l’entête PURGE permet de vider le cache Varnish, pour tester vous pouvez utiliser une extension comme postman pour envoyer l’entête sur une url bien précise. Par exemple une requête PURGE sur http://www.example.com videra le cache sur toutes les requêtes commençant par cette url, donc par exemple dans ce cas tout votre cache sera vidé. Si vous souhaitez vider seulement votre accueil vous pourrez utiliser le $ pour signaler la fin du pattern, soit http://www.example.com$. Généralement si le cache est bien vidé un code erreur 200 sera renvoyé.

Je précise toutefois que les exemples ci-dessus ne sont pas forcément valable dans tous les cas, cela dépend bien sur de votre configuration de Varnish.

A partir de là vous pouvez différencier les requêtes, mais pas les clients, et le but est tout de même de servir un cache suffisamment similaire entre visiteur pour gagner du temps. C’est là qu’intervient un truc vraiment cool, la gestion avec esi. Globalement cela va vous permettre de servir le même cache à tout le monde, mais de rendre certaines parties toujours dynamique. Par exemple, le petit bloc en haut à droite pour dire que M.Dugusse est connecté, va devoir être modifié pour être appelé par Varnish au moment de la construction du cache.

Pour se faire la méthode est assez simple, vous utiliserez des tags html, tel que

Le include va fonctionner non pas comme un include en PHP, mais plus comme un appel AJAX. J’entends par là que votre script sera indépendant du reste, vous n’aurez pas accès à ce qui à été exécuté avant (à part bien sur les sessions et autres..), car le reste sera en cache, donc non exécuté, et Varnish  appellera de manière isolée votre script durant la construction du cache et imbriquera le résultat dans la sortie HTMl. Votre script doit donc fonctionner de manière autonome. Concrètement si vous l’appelez depuis une url directe il doit s’exécuter correctement.

Est-ce que mon projet nécessite l’utilisation de Varnish ?

Varnish peut vous faire beaucoup gagner en rapidité mais inclut aussi son lot d’inconvénients. Vous ne pourrez pas l’installer du jour au lendemain sur un site de vente en ligne, il y a aura certainement beaucoup d’adaptation à faire. Dans l’idée Varnish prend tout son sens si vous avez un trafic et une charge assez importante justifiant son installation et surtout des adaptations.

En partant sur un projet neuf, vous pourrez l’implémenter assez facilement si vous partez du fait que toutes vos fonctionnalités dynamiques pourront être appelées de manière autonome (bloc d’information utilisateur, panier…). Vous aurez alors juste à rajouter des <esi include> un peu partout pour que tout fonctionne bien.

A l’inverse en partant d’un projet existant sur une plateforme type prestashop, magento, drupal… vous aurez sans doute plus de difficultés à l’implémenter sachant que certaines fonctionnalités ne sont parfois pas prévues pour fonctionner de manière autonome.

Il faut aussi prendre en compte que l’utilisation de Varnish implique des modifications assez importante et dédiées à son utilisation, donc si demain vous ne souhaitez plus l’utiliser il faudra sans doute revoir une partie du code.

Au final il faut comme d’habitude analyser, tester et voir si la solution est viable selon le projet, mais le gain potentiel est généralement non négligeable sur des sites ou applications à forte charge.

Commentaires

Laisser un commentaire