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 ?

Print Friendly, PDF & Email

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.

Écrivez-nous

Discutez directement avec notre support technique.

0256569681

Appelez-nous immédiatement pendant les heures de bureau de 9h30 à 19h30

Recevoir de l'aide

Ouvrez un ticket directement dans l'espace support.

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.

haut