Janvier 1 2019

HĂ©bergement de vernis

Qu'est-ce que le vernis ? Pourquoi choisir l'hébergement Varnish surtout si vous utilisez WordPress ou WooCommerce ?

Si vous cherchez à optimiser et accélérer l'ouverture de votre site WordPress, WooCommerce ou autre, vous serez sûrement tombé sur des articles et des conseils qui vous ont parlé de l'installation de logiciels ou de plugins Cache.

Si vous avez eu de la chance, vous aurez Ă©galement entendu certains professionnels en parler Cache de vernis, plutĂŽt que du Cache inutile cĂŽtĂ© plugin ou du Cache serveur plus banal et moins fonctionnel NGINX FastCGI Cache.

Qu'est-ce que le cache de vernis ?

Mais qu'est ce que c'est exactement Vernis et pourquoi est-ce le meilleur choix si vous décidez d'accélérer l'expérience utilisateur de votre site Web ?

Pourquoi devrais-tu le prĂ©fĂ©rez-vous aux caches php des applications comme le cache le plus rapide, Batcache, Wp Rocket, W3 Total Cache et autres ?

Varnish Cache est un logiciel cÎté serveur écrit en langage C et donc trÚs performant. Il a été conçu et développé en gardant à l'esprit les meilleurs concepts et bonnes pratiques de développement logiciel comme la gestion dynamique de la mémoire, l'utilisation de threads, la mémoire partagée, les sockets standard POSIX et bien d'autres précautions qui seraient effectivement IMPOSSIBLE avec un langage interprété comme PHP .

Tandis que les caches PHP mentionnĂ©s ci-dessus sont activĂ©s aprĂšs avoir exĂ©cutĂ© le code du cache PHP et donc engendrĂ© (gĂ©nĂ©rĂ©) un processus d'interprĂ©teur PHP via le thread PHP-FPM (Fast Process Manager), un cache Varnish rĂ©pond d'abord immĂ©diatement sans faire apparaĂźtre PHP et gĂ©nĂ©rer de nouveaux threads et processus le moins du monde, et donc d'Ă©conomiser beaucoup de CPU pour ces opĂ©rations qui peuvent ĂȘtre trĂšs lourdes devant un trafic Web trĂšs important de milliers ou dizaines de milliers de visiteurs.

Disons qu'en tant qu'hébergement WordPress géré à fort trafic, Varnish au sein de notre pile logicielle nous permet de gérer des sites avec plus de 45 millions de visiteurs uniques par mois, plus de 200 millions de pages vues et des pics de plus de 100 XNUMX utilisateurs par minute.

Dans la capture d'Ă©cran de Google Analytics ci-dessous, par exemple, un de nos clients fait 85 millions de visiteurs par mois.

 

Beaucoup de visiteurs, beaucoup de fils PHP ?

L'une des erreurs les plus courantes de ceux qui ont des pics de visiteurs de plusieurs milliers par minute est d'augmenter le nombre d'Ă©couteurs PHP-FPM afin de servir plus de connexions et de demandes entrantes.

La logique est approximativement la suivante : « Ai-je 1000 utilisateurs par minute ? Au lieu de dĂ©finir les Ă©couteurs PHP-FPM sur 32, je les ai dĂ©finis sur 512 et ainsi je pourrai rĂ©pondre Ă  plus de requĂȘtes ».

C'est l'erreur que tout le monde a (et nous avons) commise en pensant qu'il suffit d'augmenter cette valeur pour pouvoir servir plus de demandes.

Dommage que la rĂ©alitĂ© soit bien diffĂ©rente et bien qu'un nombre puisse ĂȘtre relevĂ© simplement en le changeant Ă  partir du fichier de configuration respectif du pool php-fpm, le matĂ©riel physique sous-jacent ne peut pas ĂȘtre modifiĂ© aussi facilement, donc si vous avez 8 cƓurs, il est inutile de dĂ©finir 512 threads, Ă©tant donnĂ© que ces threads devront toujours s'exĂ©cuter sur les 8 cƓurs, et donc le multiplexage et l'ordonnancement des processeurs entreront en jeu ce qui en fait permettra d'exĂ©cuter plus de processus avec des temps d'exĂ©cution plus faibles et donc beaucoup plus lents. En attendant que le processeur finira d'effectuer des opĂ©rations sur 512 pools, il y aura de nouvelles requĂȘtes entrantes Ă  traiter qui seront mises en file d'attente pour les prĂ©cĂ©dentes et ce dans quelques minutes il gĂ©nĂ©rera une file d'attente si longue qu'il faudrait des minutes ou des dizaines de minutes pour s'exĂ©cuter et donc gĂ©nĂ©rant des timeouts gĂȘnants comme le trĂšs cĂ©lĂšbre 502 portail expirĂ© o 502 Bad Gateway.

502 Passerelle incorrecte nginx

PHP craint. MySQL craint. Apache et NGINX sont nuls. WordPress ? Aussi.

Et oui, je l'ai dit. je suis une mauvaise personne. Mais je suis aussi assez réaliste, car si PHP et MySQL étaient rapides comme Node.js, GoLang et DB noSQL comme Redis.io ou MongoDB, nous n'aurions probablement pas à nous soucier des services de mise en cache car ils seraient superflus.

Malheureusement ce n'est pas le cas, et le fait que par exemple les principaux CMS utilisent la pile PHP + MySQL signifie que notre travail (et des logiciels comme Varnish) a toujours un sens et surtout une valeur. Une valeur qui peut ĂȘtre trivialement traduite en des performances plus Ă©levĂ©es en utilisant du matĂ©riel moins cher. Au final, en somme, un double avantage comme l'enseigne la recherche opĂ©rationnelle, maximiser les profits tout en minimisant les coĂ»ts.

Vernis Cache en pratique.

Pratiquement Varnish stocke les requĂȘtes GET (comme une page Web normale) et les stocke dans son stockage (qui peut ĂȘtre Ă  la fois physiquement sur disque et sur RAM) avec les avantages et inconvĂ©nients relatifs en terme de latence et donc de vitesse.

Si l'utilisateur tape https://www.sitoexample.it/company sur son navigateur, Varnish vĂ©rifiera s'il a dĂ©jĂ  la page dans le cache et s'il la fournira, sinon PASSdemandera au backend du serveur Web (normalement Apache ou NGINX) qui Ă  son tour demandera l'exĂ©cution de PHP et les requĂȘtes associĂ©es Ă  la base de donnĂ©es MySQL pour gĂ©nĂ©rer la page HTML qui sera renvoyĂ©e au serveur Web, stockĂ©e pour une utilisation future et finalement renvoyĂ©e au navigateur de l'utilisateur qui pourra enfin lire l'historique de l'entreprise de sitoexample.it

Si lors de la premiĂšre visite, par exemple, la gĂ©nĂ©ration de la page prend 1 seconde, et 50 millisecondes pour la livraison au navigateur du visiteur, lors de la deuxiĂšme visite (puisque la page est dĂ©jĂ  stockĂ©e par Varnish) la page ne doit pas ĂȘtre gĂ©nĂ©rĂ©e mais seulement envoyĂ©e Ă  l'utilisateur, donc au lieu de prendre 1 seconde et 5 millienvois, il faudra 50 millisecondes pour rechercher le Cache de vernis, 50 millisecondes pour la livraison de la page passant ainsi de 1 seconde et 50 millisecondes Ă  100 millisecondes de la deuxiĂšme visite. Bref, une Ă©conomie de 1500%.

Il est évident que dans la description que je viens de donner des caractéristiques importantes de Varnish, telles que le hachage, la récupération, la suppression des cookies, les paramÚtres, etc., ont été omises par souci de narration. fonctions absolument vitales dans certains cas qui font de Vernis précisément le fleuron des logiciels de mise en cache.

Opération de vernissage

Dans cette courte vidéo en anglais de la société mÚre Varnish-Software, vous pouvez comprendre de maniÚre trÚs élémentaire la signification d'un logiciel de cache comme Varnish.

Cache de vernis. Grands pouvoirs, grandes responsabilités.

mascotte de vernisComme pour tous les super-hĂ©ros qui se respectent (la mascotte de Varnish Cache n'est qu'un lapin de super-hĂ©ros) de grandes puissances correspondent Ă  de grandes responsabilitĂ©s. 

S'il est vrai que Varnish est le meilleur logiciel de cache web, il est également vrai que fondamentalement c'est un logiciel stupide qui ne fait que ce qu'on lui demande de faire à travers une configuration précise et méticuleuse à la fois de Varnish et de l'application qui doit s'exécuter dessus.

Parmi les questions importantes que tout développeur, ingénieur systÚme et utilisateur de Varnish devrait se poser, y a-t-il par exemple ?

 

Combien de temps le cache doit-il durer ?

Car s'il est vrai que la page de prĂ©sentation institutionnelle d'une entreprise peut subir 1 ou 2 changements par an, peut-ĂȘtre la gestion d'un blog de football qui rapporte en temps rĂ©el un match de football de Serie A, il faudra mettre Ă  jour la page en direct pour chaque action marquante du match de football, qu'il s'agisse d'un carton jaune, d'un carton rouge, d'un penalty ou d'un but marquĂ© avec l'explosion du stade avec enthousiasme.

Comment gĂ©rer les pages AMP avec Cache ?

Nous savons qu'avec l'avÚnement de l'AMP, de nombreux facteurs en jeu ont changé concernant le positionnement, le référencement en temps réel et les services trÚs rentables en termes de trafic comme Google News. L'un des problÚmes les plus fréquents concerne la gestion des pages AMP, c'est-à-dire aux services Google que le contenu de la publication a été mis à jour et donc également que le contenu AMP respectif a été modifié.

Comment gérer les cookies inutiles, les laisser passer ?

Si un plugin stupide et inutile me place un cookie cÎté serveur, il invalidera le cache. Alors comment gérer cet aspect ? La laisse-t-on passer, l'élimine-t-on ? Avec quelles précautions ?

Et les gros fichiers ?

Est-il judicieux pour un site avec beaucoup de contenu statique (images, iso, fichiers d'archive zip, rar par exemple) de mettre en cache ce contenu qui est dĂ©jĂ  beau et prĂȘt tout seul ? Est-il judicieux de lire un fichier iso de 4 Go, de le mettre dans le cache, puis de le rĂ©cupĂ©rer dans le cache en le renvoyant au navigateur ? Ou peut-ĂȘtre est-il plus logique de transmettre la demande directement au serveur Web qui dĂ©marrera immĂ©diatement avec le flux de fichiers sans attente ni mise en cache inutiles ?

Comment gérer les pages utilisateurs d'un Ecommerce ?

Que se passe-t-il si, par exemple, sur un site WooCommerce avec Varnish, malgré un catalogue partagé, le panier est également mis en cache ? Vais-je voir mes produits ou ceux d'autres utilisateurs ? Que faire si l'utilisateur est connecté avec ses identifiants dans son espace privé ? Allez-vous voir vos données et factures ou celles d'autres clients ? Cet aspect aujourd'hui plus que jamais à la lumiÚre des nouvelles rÚgles européennes sur la vie privée (RGPD) est trÚs important.

Comment gérer les URL de suivi paramétriques comme fbclid ou utm avec Varnish ?

Que se passe-t-il si, par exemple, sur un site WooCommerce avec Varnish on dĂ©cide d'utiliser une campagne publicitaire Facebook oĂč le lien sortant de la plateforme Facebook ajoute un paramĂštre du type fbclid = stringarandom pour chaque utilisateur Ă  l'url ? Comment empĂȘcher cette chaĂźne de contourner mon cache Varnish, rendant le site lent comme s'il n'y avait pas de cache dessus ? Comment gĂ©rer Ă©lĂ©gamment cette situation sans mettre moins de fonctionnalitĂ© de suivi du paramĂštre fbclid (ou d'autres paramĂštres de suivi comme l'UTM de Google) ?

Comment utiliser Varnish avec HTTPS ?

Cela peut sembler stupide, mais avec le passage "forcĂ©" de Google de HTTP Ă  HTTPS, nous avons vu de nombreux fournisseurs italiens et internationaux abandonner Varnish en tant que systĂšme de Caching car il est incompatible avec le protocole HTTPS pour convertir en LiteSpeed ​​Cache. Nous avons certainement grandement bĂ©nĂ©ficiĂ© en continuant Ă  utiliser le Varnish, beaucoup plus polyvalent et performant, en l'adaptant pour une utilisation avec HTTPS et HTTP2. Ce choix nous a permis de nous Ă©lever en termes de qualitĂ© et de doubler les bĂ©nĂ©fices et le chiffre d'affaires l'annĂ©e derniĂšre.

Installer Varnish Supercache est différent de faire fonctionner Varnish.

Si Ă  ce stade vous avez pensĂ© Ă  installer Varnish ou Ă  le faire sur l'un des rares hĂ©bergements qui sponsorisent Varnish parmi leurs solutions prĂ©configurĂ©es, sachez que Varnish ne se contente pas de l'installer ou de l'acheter en tant que service d'un fournisseur d'hĂ©bergement, mais il doit ĂȘtre installĂ©, configurĂ© cĂŽtĂ© serveur selon le cahier des charges du projet et configurĂ© sur le projet WordPress par exemple (dans le backend) pour que toutes les fonctions de nettoyage du cache (purge), du plan du site, pages AMP, articles instantanĂ©s, pages utilisateur, de la gestion de gĂąteau, et bien plus encore.

S'ils ne vous proposent pas une solution sur mesure, complĂ©tĂ©e par un ingĂ©nieur systĂšme senior qui vous suivra tout au long de la phase initiale de la migration Ă  la configuration en passant par le rĂ©glage, vous achetez trĂšs probablement quelque chose qui Ă  court et moyen terme, cela causera de gros dommages Ă  votre site. En ne mettant pas Ă  jour les sitemaps par exemple, vous risquez de ne pas voir d'indexation sur Google pour vos nouveaux articles, un dysfonctionnement AMP vous expulsera de Google News, et des problĂšmes similaires encore plus graves qui ont vu dans certains cas littĂ©ralement la mort du site de ceux qui ont essayĂ© de le faire eux-mĂȘmes.

Au mieux vous vous retrouverez avec un Varnish installĂ© qui ne chie rien et laisse passer toutes les requĂȘtes vers le serveur Web et par la suite PHP et MySQL.

Si votre besoin est d'accélérer un site WordPress ou WooCommerce, gérer des pics de trafic élevés et de nombreux utilisateurs, contactez-nous, nous avons pour vous les meilleures solutions technologiques, des systÚmes au meilleur prix.

Contactez-nous maintenant.

 

Vous avez des doutes ? Vous ne savez pas par oĂč commencer ? Contactez-nous


Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

ManagedServer.it est le premier fournisseur italien de solutions d'hébergement hautes performances. Notre modÚle d'abonnement est abordable et prévisible, afin que les clients puissent accéder à nos technologies d'hébergement fiables, à nos serveurs dédiés et au cloud. ManagedServer.it offre également d'excellents services d'assistance et de conseil sur l'hébergement des principaux CMS Open Source tels que WordPress, WooCommerce, Drupal, Prestashop, Magento.

Remonter en haut