{"id":2886,"date":"2012-08-29T09:56:33","date_gmt":"2012-08-29T09:56:33","guid":{"rendered":"https:\/\/www.combell.com\/fr\/blog\/?p=2886"},"modified":"2022-11-17T15:45:52","modified_gmt":"2022-11-17T14:45:52","slug":"des-sites-ultrarapides-avec-varnish","status":"publish","type":"post","link":"https:\/\/www.combell.com\/fr\/blog\/des-sites-ultrarapides-avec-varnish\/","title":{"rendered":"Des sites ultrarapides avec Varnish"},"content":{"rendered":"<address><a href=\"https:\/\/www.combell.com\/fr\/blog\/files\/2012\/08\/Varnish.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"alignright size-thumbnail wp-image-2888\" title=\"Varnish\" src=\"https:\/\/www.combell.com\/fr\/blog\/files\/2012\/08\/Varnish-150x150.jpg\" alt=\"\" width=\"150\" height=\"150\" \/><\/a>Auteur: Thijs Feryn, Hosting Evangelist chez Combell<\/address>\n<address>\u00a0<\/address>\n<p>Durant la phase de d\u00e9veloppement, le site fonctionne \u00e0 une vitesse \u00e9poustouflante, mais d\u00e8s qu'il entre en phase de production et qu\u2019il est rendu accessible au grand public, il ne fonctionne plus correctement. Voil\u00e0 la triste r\u00e9alit\u00e9 \u00e0 laquelle nous sommes confront\u00e9s au quotidien en tant qu\u2019h\u00e9bergeur.<\/p>\n<p><strong>Sites lents<\/strong><\/p>\n<p>Malheureusement, aujourd\u2019hui encore, de tr\u00e8s nombreux d\u00e9veloppeurs n\u2019accordent toujours pas assez d\u2019attention aux <strong>performances et \u00e0 l\u2019extensibilit\u00e9<\/strong>. Pourtant, dans le monde d\u2019Internet, mais aussi dans les diverses communaut\u00e9s de d\u00e9veloppeurs sp\u00e9cialis\u00e9s, cela fait d\u00e9j\u00e0 un certain temps que l\u2019on r\u00e9p\u00e8te que l\u2019extensibilit\u00e9 commence d\u00e8s la conception de l\u2019<strong>architecture<\/strong> d\u2019une application ou d\u2019un site.<\/p>\n<p>Les divers frameworks avec lesquels les sites web sont cr\u00e9\u00e9s sont eux aussi de plus en plus \u00e9quip\u00e9s des outils permettant au site d\u2019\u00eatre plus rapide.<\/p>\n<p>Mais la n\u00e9gligence ou l\u2019ignorance ne sont pas toujours \u00e0 l\u2019origine de la lenteur d\u2019un site. Dans certains cas, il s\u2019agit d\u2019un <strong>concours de circonstances:<\/strong><\/p>\n<p><!--more--><\/p>\n<ul>\n<li>Un nombre de visiteurs plus important qu\u2019on l\u2019avait imagin\u00e9 au d\u00e9part<\/li>\n<li>Une plus grande concentration du nombre de visiteurs<\/li>\n<li>Des serveurs pas assez puissants<\/li>\n<li>Un mauvais r\u00e9glage des logiciels<\/li>\n<li>Une mauvaise conception des bases de donn\u00e9es et une mauvaise indexation<\/li>\n<li>L\u2019utilisation de composants tiers lents ou instables.<\/li>\n<\/ul>\n<p><strong>Interventions<\/strong><\/p>\n<p>Durant la phase de d\u00e9veloppement, il est naturellement toujours difficile d\u2019effectuer un test de r\u00e9sistance r\u00e9aliste. De ce fait, ce n\u2019est souvent que lorsque de nombreux visiteurs se rendent sur le site lors de la phase de production que les probl\u00e8mes apparaissent.<\/p>\n<p>Dans de telles situations, il est souvent trop tard et nous devons intervenir en notre qualit\u00e9 d\u2019h\u00e9bergeur. Une des possibilit\u00e9s consiste \u00e0 utiliser plus de serveurs. Il pourrait s\u2019agir d\u2019une strat\u00e9gie tr\u00e8s lucrative pour nous, mais nous adoptons g\u00e9n\u00e9ralement une approche plus pragmatique: les applications ne peuvent pas toutes tourner de mani\u00e8re efficace sur plusieurs serveurs et, souvent, les probl\u00e8mes de performances peuvent \u00eatre solutionn\u00e9s en utilisant une bonne <strong>mise en cache.<\/strong><\/p>\n<p><strong>M\u00e9moire cache<\/strong><\/p>\n<p>La mise en cache est une technique qui consiste \u00e0 conserver des <strong>donn\u00e9es dynamiques<\/strong> (des donn\u00e9es qui sont calcul\u00e9es) sous forme <strong>statique<\/strong>, ce qui permet d\u2019obtenir une <strong>am\u00e9lioration des performances.<\/strong><\/p>\n<p>Lors de l\u2019utilisation de la m\u00e9moire cache, il faut h\u00e9las aussi faire des compromis: les donn\u00e9es dynamiques deviennent statiques et il y a par cons\u00e9quent un risque qu\u2019en raison de la mise en cache, des <strong>donn\u00e9es inactuelles soient affich\u00e9es<\/strong>. En appliquant une strat\u00e9gie <strong>d\u2019expiration ou d\u2019invalidation bien r\u00e9fl\u00e9chie<\/strong>, on peut faire en sorte que des donn\u00e9es actuelles se retrouvent sur le site.<\/p>\n<p>La plupart des formes de m\u00e9moire cache doivent malheureusement \u00eatre int\u00e9gr\u00e9es dans la programmation du site et sont par cons\u00e9quent des d\u00e9cisions architecturales. Lorsque aucune m\u00e9moire cache correcte n\u2019est pr\u00e9vue, des probl\u00e8mes apparaissent.<\/p>\n<p><strong>Proxy inverse<\/strong><\/p>\n<p>Heureusement, il existe des proxys inverses. On se souvient encore des serveurs proxy du temps o\u00f9 les connexions Internet \u00e9taient encore lentes : les serveurs proxy permettaient de conserver le contenu des sites visit\u00e9s afin que ce dernier ne doive pas constamment \u00eatre charg\u00e9 depuis cet Internet si lent.<\/p>\n<p>Aujourd\u2019hui, les connexions Internet sont bien plus rapides qu\u2019auparavant et un proxy inverse fait, comme son nom l\u2019indique, l\u2019inverse : le serveur ne se trouve pas du c\u00f4t\u00e9 de l\u2019utilisateur, mais bien dans le centre de donn\u00e9es. Un proxy inverse prot\u00e8ge les serveurs d\u2019une grande quantit\u00e9 inattendue de visiteurs.<\/p>\n<p>Comment un proxy inverse fait-il cela ? En (par analogie avec un proxy ordinaire) mettant en cache les r\u00e9sultats des serveurs en les fournissant sous forme statique aux visiteurs. Ainsi, une requ\u00eate ne doit pas toujours passer par les serveurs back-end et les sites web deviennent plus rapides. <strong>Varnish est un proxy inverse de ce type. \u00a0<\/strong><\/p>\n<p><strong>Varnish<\/strong><\/p>\n<p>Varnish est un logiciel de proxy inverse open source, d\u00e9velopp\u00e9 par la soci\u00e9t\u00e9 norv\u00e9gienne LinPro. Ce qui a d\u00e9but\u00e9 en tant que projet dont le but \u00e9tait d\u2019acc\u00e9l\u00e9rer un site d\u2019actualit\u00e9s norv\u00e9gien est finalement devenu un projet qui est aujourd\u2019hui consid\u00e9r\u00e9 comme un <em>\u00ab standard de l\u2019industrie \u00bb.<\/em><\/p>\n<p><a title=\"Varnish\" href=\"https:\/\/varnish-cache.org\/\" target=\"_blank\" rel=\"noopener\">Varnish <\/a>peut \u00eatre facilement install\u00e9 sur un serveur Linux et est plac\u00e9 avant le(s) serveur(s) web. En cr\u00e9ant un lien entre les enregistrements DNS du site (p. ex. <a title=\"www.nomdedomaine.be\" href=\"http:\/\/www.nomdedomaine.be\" target=\"_blank\" rel=\"noopener\">www.nomdedomaine.be<\/a>) et Varnish, ce dernier prot\u00e8ge vos serveurs back-end des charges trop importantes.<\/p>\n<p><strong>Varnish parle le HTTP<\/strong><\/p>\n<p>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\u2019agit du protocole utilis\u00e9 par convention pour le trafic web sur Internet.<\/p>\n<p>Dans ses sp\u00e9cifications, HTTP a pr\u00e9vu un m\u00e9canisme de mise en cache, que l\u2019on appelle souvent le \u201c<strong>cache du navigateur<\/strong>\u201d.\u00a0 Tout comme les serveurs proxy, le cache du navigateur \u00e9tait autrefois utilis\u00e9 pour compenser le fait que les connexions Internet \u00e9taient lentes. La mise en cache HTTP est aujourd\u2019hui aussi utilis\u00e9e pour modifier le comportement des proxys inverses. Ce comportement est clairement d\u00e9crit dans le <a title=\"chapitre 14.9\" href=\"http:\/\/www.w3.org\/Protocols\/rfc2616\/rfc2616-sec14.html#sec14.9\" target=\"_blank\" rel=\"noopener\">chapitre 14.9<\/a> des <a title=\"sp\u00e9cifications HTTP\" href=\"http:\/\/www.w3.org\/Protocols\/rfc2616\/rfc2616.html\" target=\"_blank\" rel=\"noopener\">sp\u00e9cifications HTTP<\/a>.<\/p>\n<p>On pr\u00e9f\u00e8rera toujours mettre le plus possible en cache, mais il est bien s\u00fbr impossible de tout mettre en cache. Quand Varnish ne met-il pas en cache ?<\/p>\n<ul>\n<li>Quand des cookies sont pr\u00e9sents (ce qui indique qu\u2019il s\u2019agit de contenu propre \u00e0 l\u2019utilisateur).<\/li>\n<li>Quand le time to live des en-t\u00eates Cache-Control est inf\u00e9rieur ou \u00e9gal \u00e0 z\u00e9ro.<\/li>\n<li>Quand la requ\u00eate du visiteur n\u2019est pas une requ\u00eate de type GET (un POST, PUT ou DELETE donc).<\/li>\n<li>Quand le back-end demande l\u2019authentification de l\u2019utilisateur.<\/li>\n<\/ul>\n<p>Tout ce qui ne r\u00e9pond pas aux crit\u00e8res susmentionn\u00e9s sera mis en cache par Varnish. La validit\u00e9\/dur\u00e9e du cache pour une page est d\u00e9termin\u00e9e par le time to live de l\u2019en-t\u00eate Cache-Control. Si celui-ci est r\u00e9gl\u00e9 sur 3600 secondes, la page est mise en cache durant une heure.<\/p>\n<p><strong>Langage de Configuration de Varnish<\/strong><\/p>\n<p>Dans le paragraphe pr\u00e9c\u00e9dent, on a d\u00e9crit le comportement standard de Varnish et ce qui peut \u00eatre mis en cache ou non.<\/p>\n<p>Souvent, des sc\u00e9narios ne sont pas souhaitables pour des logiciels existants qui contreviennent parfois \u00e0 ces r\u00e8gles. Heureusement, Varnish int\u00e8gre un langage de programmation permettant de personnaliser le comportement de Varnish.<\/p>\n<p>Au moyen du <a title=\"Varnish Configuration Language (VCL), \" href=\"https:\/\/varnish-cache.org\/docs\/3.0\/reference\/vcl.html\" target=\"_blank\" rel=\"noopener\">Varnish Configuration Language (VCL), <\/a>on peut g\u00e9rer divers composants de la m\u00e9moire cache de Varnish et on peut d\u00e9terminer, l\u00e0 o\u00f9 cela est n\u00e9cessaire, ce qui doit \u00eatre mis en cache ou non dans des circonstances bien d\u00e9finies.<\/p>\n<p>Voici quelques-unes des actions les plus courantes pouvant \u00eatre effectu\u00e9es via le VCL :<\/p>\n<ul>\n<li>La suppression de certains cookies l\u00e0 o\u00f9 ils ne sont pas n\u00e9cessaires, afin que certaines pages ou autres documents puissent tout de m\u00eame \u00eatre mis en cache.<\/li>\n<li>La mise en cache (ou non) explicite de certaines URL.<\/li>\n<li>La d\u00e9termination de la dur\u00e9e de conservation en m\u00e9moire cache de pages sp\u00e9cifiques.<\/li>\n<li>L\u2019\u00e9laboration d\u2019un m\u00e9canisme d\u2019invalidation permettant \u00e0 certaines pages d\u2019\u00eatre supprim\u00e9es de la m\u00e9moire cache, m\u00eame si le time to live n\u2019est pas \u00e9coul\u00e9.<\/li>\n<li>La r\u00e9\u00e9criture d\u2019en-t\u00eates HTTP.<\/li>\n<li>L\u2019int\u00e9gration de certaines donn\u00e9es de cookies dans la cl\u00e9 d\u2019identification de la m\u00e9moire cache.<\/li>\n<li>L\u2019\u00e9quilibrage des charges de requ\u00eates vers des serveurs back-end sp\u00e9cifiques.<\/li>\n<li>La d\u00e9termination de la mani\u00e8re dont Varnish doit r\u00e9agir lorsque les serveurs back-end sont en panne ou ne r\u00e9agissent pas \u00e0 temps.<\/li>\n<li>\u2026<\/li>\n<\/ul>\n<p>Chaque site est diff\u00e9rent et requiert une configuration VCL diff\u00e9rente. Il est important que le d\u00e9veloppeur du site puisse inventorier les diverses URL et d\u00e9finir quels cookies doivent \u00eatre utilis\u00e9s et \u00e0 quel endroit. Ce n\u2019est qu\u2019ensuite qu\u2019il est possible de configurer Varnish de mani\u00e8re id\u00e9ale.<\/p>\n<p><strong>Vitesse<\/strong><\/p>\n<p>Varnish est rapide. Sacr\u00e9ment rapide m\u00eame ! C\u2019est un outil qui peut faire peu de choses, qui doit pouvoir faire peu de choses, et c\u2019est pour cela qu\u2019il est si efficace. Il n\u2019est pratiquement pas question d\u2019overhead et tous les \u00e9l\u00e9ments mis en cache sont conserv\u00e9s par d\u00e9faut dans la m\u00e9moire RAM.<\/p>\n<p>Quelques tests cibl\u00e9s que nous avons effectu\u00e9s ont montr\u00e9 que des installations lentes peuvent fonctionner jusqu\u2019\u00e0 500 fois plus rapidement gr\u00e2ce \u00e0 Varnish. Mais ces chiffres ne disent pas tout. Le gain de performances net d\u00e9pend souvent de la lenteur de l\u2019installation initiale, du nombre d\u2019URL diff\u00e9rentes devant \u00eatre mises en cache et de la mani\u00e8re dont les visiteurs surfent sur le site.<\/p>\n<p>Ce qui est certain, c\u2019est que la plupart des grands acteurs du web utilisent cette technologie. En 2009, une \u00e9tude de cas avait d\u00e9j\u00e0 \u00e9t\u00e9 r\u00e9alis\u00e9e sur la mani\u00e8re dont NU.nl (le site le plus visit\u00e9 aux Pays-Bas) a pu enregistrer jusqu\u2019\u00e0 21 millions d\u2019utilisateurs en un jour, entre autres gr\u00e2ce \u00e0 l\u2019utilisation Varnish.<\/p>\n<p><strong>Varnish chez Combell<\/strong><\/p>\n<p>Chez Combell aussi, cela fait maintenant quelques ann\u00e9es que nous utilisons Varnish, qui forme la pierre angulaire de tr\u00e8s nombreuses installations. Nous utilisons g\u00e9n\u00e9ralement Varnish comme joker lorsqu\u2019un site existant fournit de mauvaises performances, mais nous pr\u00e9voyons souvent Varnish d\u00e8s la conception du plan initial.<\/p>\n<p>Certains de nos clients ont r\u00e9gl\u00e9 leurs logiciels existants de mani\u00e8re \u00e0 pouvoir r\u00e9aliser, gr\u00e2ce \u00e0 Varnish, une plus grande croissance avec du mat\u00e9riel existant.<\/p>\n<p>D\u2019autres clients utilisent quant \u00e0 eux Varnish comme alternative bon march\u00e9 et \u00e9quivalente \u00e0 leurs solutions Content Delivery Network (CDN) on\u00e9reuses. Ces clients utilisent surtout la m\u00e9moire cache et, en moindre mesure, la distribution g\u00e9ographique des m\u00e9moires cache.<\/p>\n<p>Il est donc clair que, chez nous, Varnish est tr\u00e8s appr\u00e9ci\u00e9. Nous investissons de ce fait suffisamment dans des connaissances concernant cette technologie. Certains membres de notre \u00e9quipe seront m\u00eame pr\u00e9sents au <a title=\"Varnish User Group Meeting \u00e0 Londres\" href=\"https:\/\/varnish-cache.org\/\" target=\"_blank\" rel=\"noopener\">Varnish User Group Meeting \u00e0 Londres<\/a>.<\/p>\n<p>Nous essayons \u00e9galement de partager le plus de connaissances possible via des expos\u00e9s. Thijs Feryn, notre \u00e9vang\u00e9liste technologique, pr\u00e9sente des <a title=\"expos\u00e9s dans le monde entier \" href=\"http:\/\/talks.feryn.eu\/\" target=\"_blank\" rel=\"noopener\">expos\u00e9s dans le monde entier <\/a>au sujet de Varnish, des performances et de l\u2019extensibilit\u00e9 en g\u00e9n\u00e9ral. Dans cette <a title=\"vid\u00e9o sur Vimeo\" href=\"http:\/\/vimeo.com\/21186971\" target=\"_blank\" rel=\"noopener\">vid\u00e9o sur Vimeo<\/a>, vous pourrez visionner un expos\u00e9 que Thijs a pr\u00e9sent\u00e9 \u00e0 Londres en 2011.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Auteur: Thijs Feryn, Hosting Evangelist chez Combell \u00a0 Durant la phase de d\u00e9veloppement, le site fonctionne \u00e0 une vitesse \u00e9poustouflante, mais d\u00e8s qu'il entre en phase de production et qu\u2019il...<\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_uag_custom_page_level_css":"","footnotes":""},"categories":[67,68],"tags":[],"acf":[],"uagb_featured_image_src":{"full":false,"thumbnail":false,"medium":false,"medium_large":false,"large":false,"1536x1536":false,"2048x2048":false,"post-featured":false,"post-featured-opt":false,"post-featured-opt-md":false,"post-featured-opt-sm":false,"post-featured-opt-xs":false,"post-most-popular":false,"post-author":false},"uagb_author_info":{"display_name":"Romy","author_link":"https:\/\/www.combell.com\/fr\/blog\/author\/romy\/"},"uagb_comment_info":0,"uagb_excerpt":"Auteur: Thijs Feryn, Hosting Evangelist chez Combell \u00a0 Durant la phase de d\u00e9veloppement, le site fonctionne \u00e0 une vitesse \u00e9poustouflante, mais d\u00e8s qu'il entre en phase de production et qu\u2019il...","_links":{"self":[{"href":"https:\/\/www.combell.com\/fr\/blog\/wp-json\/wp\/v2\/posts\/2886"}],"collection":[{"href":"https:\/\/www.combell.com\/fr\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.combell.com\/fr\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.combell.com\/fr\/blog\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/www.combell.com\/fr\/blog\/wp-json\/wp\/v2\/comments?post=2886"}],"version-history":[{"count":6,"href":"https:\/\/www.combell.com\/fr\/blog\/wp-json\/wp\/v2\/posts\/2886\/revisions"}],"predecessor-version":[{"id":7764,"href":"https:\/\/www.combell.com\/fr\/blog\/wp-json\/wp\/v2\/posts\/2886\/revisions\/7764"}],"wp:attachment":[{"href":"https:\/\/www.combell.com\/fr\/blog\/wp-json\/wp\/v2\/media?parent=2886"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.combell.com\/fr\/blog\/wp-json\/wp\/v2\/categories?post=2886"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.combell.com\/fr\/blog\/wp-json\/wp\/v2\/tags?post=2886"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}