Des sites ultrarapides avec Varnish

Auteur: Thijs Feryn, Hosting Evangelist chez Combell

Durant la phase de développement, le site fonctionne à une vitesse époustouflante, mais dès qu'il entre en phase de production et qu’il est rendu accessible au grand public, il ne fonctionne plus correctement. Voilà la triste réalité à laquelle nous sommes confrontés au quotidien en tant qu’hébergeur.

Sites lents

Malheureusement, aujourd’hui encore, de très nombreux développeurs n’accordent toujours pas assez d’attention aux performances et à l’extensibilité. Pourtant, dans le monde d’Internet, mais aussi dans les diverses communautés de développeurs spécialisés, cela fait déjà un certain temps que l’on répète que l’extensibilité commence dès la conception de l’architecture d’une application ou d’un site.

Les divers frameworks avec lesquels les sites web sont créés sont eux aussi de plus en plus équipés des outils permettant au site d’être plus rapide.

Mais la négligence ou l’ignorance ne sont pas toujours à l’origine de la lenteur d’un site. Dans certains cas, il s’agit d’un concours de circonstances:

• Un nombre de visiteurs plus important qu’on l’avait imaginé au départ
• Une plus grande concentration du nombre de visiteurs
• Des serveurs pas assez puissants
• Un mauvais réglage des logiciels
• Une mauvaise conception des bases de données et une mauvaise indexation
• L’utilisation de composants tiers lents ou instables.

Interventions

Durant la phase de développement, il est naturellement toujours difficile d’effectuer un test de résistance réaliste. De ce fait, ce n’est souvent que lorsque de nombreux visiteurs se rendent sur le site lors de la phase de production que les problèmes apparaissent.

Dans de telles situations, il est souvent trop tard et nous devons intervenir en notre qualité d’hébergeur. Une des possibilités consiste à utiliser plus de serveurs. Il pourrait s’agir d’une stratégie très lucrative pour nous, mais nous adoptons généralement une approche plus pragmatique: les applications ne peuvent pas toutes tourner de manière efficace sur plusieurs serveurs et, souvent, les problèmes de performances peuvent être solutionnés en utilisant une bonne mise en cache.

Mémoire cache

La mise en cache est une technique qui consiste à conserver des données dynamiques (des données qui sont calculées) sous forme statique, ce qui permet d’obtenir une amélioration des performances.

Lors de l’utilisation de la mémoire cache, il faut hélas aussi faire des compromis: les données dynamiques deviennent statiques et il y a par conséquent un risque qu’en raison de la mise en cache, des données inactuelles soient affichées. En appliquant une stratégie d’expiration ou d’invalidation bien réfléchie, on peut faire en sorte que des données actuelles se retrouvent sur le site.

La plupart des formes de mémoire cache doivent malheureusement être intégrées dans la programmation du site et sont par conséquent des décisions architecturales. Lorsque aucune mémoire cache correcte n’est prévue, des problèmes apparaissent.

Proxy inverse

Heureusement, il existe des proxys inverses. On se souvient encore des serveurs proxy du temps où les connexions Internet étaient encore lentes : les serveurs proxy permettaient de conserver le contenu des sites visités afin que ce dernier ne doive pas constamment être chargé depuis cet Internet si lent.

Aujourd’hui, les connexions Internet sont bien plus rapides qu’auparavant et un proxy inverse fait, comme son nom l’indique, l’inverse : le serveur ne se trouve pas du côté de l’utilisateur, mais bien dans le centre de données. Un proxy inverse protège les serveurs d’une grande quantité inattendue de visiteurs.

Comment un proxy inverse fait-il cela ? En (par analogie avec un proxy ordinaire) mettant en cache les résultats des serveurs en les fournissant sous forme statique aux visiteurs. Ainsi, une requête ne doit pas toujours passer par les serveurs back-end et les sites web deviennent plus rapides. Varnish est un proxy inverse de ce type.  

Varnish

Varnish est un logiciel de proxy inverse open source, développé par la société norvégienne LinPro. Ce qui a débuté en tant que projet dont le but était d’accélérer un site d’actualités norvégien est finalement devenu un projet qui est aujourd’hui considéré comme un « standard de l’industrie ».

Varnish peut être facilement installé sur un serveur Linux et est placé avant le(s) serveur(s) web. En créant un lien entre les enregistrements DNS du site (p. ex. www.nomdedomaine.be) et Varnish, ce dernier protège vos serveurs back-end des charges trop importantes.

Varnish parle le HTTP

Du fait que Varnish est un proxy qui jette un pont entre le navigateur et le serveur, il est logique que Varnish parle le HTTP. Il s’agit du protocole utilisé par convention pour le trafic web sur Internet.

Dans ses spécifications, HTTP a prévu un mécanisme de mise en cache, que l’on appelle souvent le “cache du navigateur”.  Tout comme les serveurs proxy, le cache du navigateur était autrefois utilisé pour compenser le fait que les connexions Internet étaient lentes. La mise en cache HTTP est aujourd’hui aussi utilisée pour modifier le comportement des proxys inverses. Ce comportement est clairement décrit dans le chapitre 14.9 des spécifications HTTP.

On préfèrera toujours mettre le plus possible en cache, mais il est bien sûr impossible de tout mettre en cache. Quand Varnish ne met-il pas en cache ?

• Quand des cookies sont présents (ce qui indique qu’il s’agit de contenu propre à l’utilisateur).
• Quand le time to live des en-têtes Cache-Control est inférieur ou égal à zéro.
• Quand la requête du visiteur n’est pas une requête de type GET (un POST, PUT ou DELETE donc).
• Quand le back-end demande l’authentification de l’utilisateur.

Tout ce qui ne répond pas aux critères susmentionnés sera mis en cache par Varnish. La validité/durée du cache pour une page est déterminée par le time to live de l’en-tête Cache-Control. Si celui-ci est réglé sur 3600 secondes, la page est mise en cache durant une heure.

Langage de Configuration de Varnish

Dans le paragraphe précédent, on a décrit le comportement standard de Varnish et ce qui peut être mis en cache ou non.

Souvent, des scénarios ne sont pas souhaitables pour des logiciels existants qui contreviennent parfois à ces règles. Heureusement, Varnish intègre un langage de programmation permettant de personnaliser le comportement de Varnish.

Au moyen du Varnish Configuration Language (VCL), on peut gérer divers composants de la mémoire cache de Varnish et on peut déterminer, là où cela est nécessaire, ce qui doit être mis en cache ou non dans des circonstances bien définies.

Voici quelques-unes des actions les plus courantes pouvant être effectuées via le VCL :

• La suppression de certains cookies là où ils ne sont pas nécessaires, afin que certaines pages ou autres documents puissent tout de même être mis en cache.
• La mise en cache (ou non) explicite de certaines URL.
• La détermination de la durée de conservation en mémoire cache de pages spécifiques.
• L’élaboration d’un mécanisme d’invalidation permettant à certaines pages d’être supprimées de la mémoire cache, même si le time to live n’est pas écoulé.
• La réécriture d’en-têtes HTTP.
• L’intégration de certaines données de cookies dans la clé d’identification de la mémoire cache.
• L’équilibrage des charges de requêtes vers des serveurs back-end spécifiques.
• La détermination de la manière dont Varnish doit réagir lorsque les serveurs back-end sont en panne ou ne réagissent pas à temps.
• …

Chaque site est différent et requiert une configuration VCL différente. Il est important que le développeur du site puisse inventorier les diverses URL et définir quels cookies doivent être utilisés et à quel endroit. Ce n’est qu’ensuite qu’il est possible de configurer Varnish de manière idéale.

Vitesse

Varnish est rapide. Sacrément rapide même ! C’est un outil qui peut faire peu de choses, qui doit pouvoir faire peu de choses, et c’est pour cela qu’il est si efficace. Il n’est pratiquement pas question d’overhead et tous les éléments mis en cache sont conservés par défaut dans la mémoire RAM.

Quelques tests ciblés que nous avons effectués ont montré que des installations lentes peuvent fonctionner jusqu’à 500 fois plus rapidement grâce à Varnish. Mais ces chiffres ne disent pas tout. Le gain de performances net dépend souvent de la lenteur de l’installation initiale, du nombre d’URL différentes devant être mises en cache et de la manière dont les visiteurs surfent sur le site.

Ce qui est certain, c’est que la plupart des grands acteurs du web utilisent cette technologie. En 2009, une étude de cas avait déjà été réalisée sur la manière dont NU.nl (le site le plus visité aux Pays-Bas) a pu enregistrer jusqu’à 21 millions d’utilisateurs en un jour, entre autres grâce à l’utilisation Varnish.

Varnish chez Combell

Chez Combell aussi, cela fait maintenant quelques années que nous utilisons Varnish, qui forme la pierre angulaire de très nombreuses installations. Nous utilisons généralement Varnish comme joker lorsqu’un site existant fournit de mauvaises performances, mais nous prévoyons souvent Varnish dès la conception du plan initial.

Certains de nos clients ont réglé leurs logiciels existants de manière à pouvoir réaliser, grâce à Varnish, une plus grande croissance avec du matériel existant.

D’autres clients utilisent quant à eux Varnish comme alternative bon marché et équivalente à leurs solutions Content Delivery Network (CDN) onéreuses. Ces clients utilisent surtout la mémoire cache et, en moindre mesure, la distribution géographique des mémoires cache.

Il est donc clair que, chez nous, Varnish est très apprécié. Nous investissons de ce fait suffisamment dans des connaissances concernant cette technologie. Certains membres de notre équipe seront même présents au Varnish User Group Meeting à Londres.

Nous essayons également de partager le plus de connaissances possible via des exposés. Thijs Feryn, notre évangéliste technologique, présente des exposés dans le monde entier au sujet de Varnish, des performances et de l’extensibilité en général. Dans cette vidéo sur Vimeo, vous pourrez visionner un exposé que Thijs a présenté à Londres en 2011.