Table des matières de l'article :
Il y a quelques semaines, nous avons parlé de la façon dont en octobre le site Birredamanicomio.com s'est déconnecté lors d'un passage promotionnel dans une publicité télévisée sur X Factor. Nous avons fait une analyse assez claire et objective des lacunes et des carences qui ont conduit à la panne de ce site hébergé non pas par nous mais par un autre hébergeur, expliquant comment l'absence de cache statique avait été cruciale pour le crash que nous voulions également documenter avec un enregistrement vidéo du smartphone toujours à cet article intitulé justement Comment ne pas passer à la télé avec votre site WooCommerce s'il n'est pas correctement configuré côté Serveur et Hébergement.
Même pas pour le faire exprès, en moins d'un mois, nous avons l'occasion de montrer avec des faits toute la théorie dont nous nous sommes dispensés avec de belles paroles dans l'article précédent qui dénotait le temps d'arrêt et le crash du serveur d'un de nos concurrents et concurrents.
Le cas précis : X-Bio sur RAI1 et l'héritage avec Flavio Insinna.
X-Bio est la marque d'un de nos clients (Buoninfante Medical Group) qui produit des matelas de haute qualité et de qualité qui a lancé un lancement national réservé aux X-BIO Circulif, nouveau modèle de la ligne X-BIO par Buoninfante - marque du fabricant de matelas née en 1975. Du lundi 7 au vendredi 11 novembre X-BIO Circulife sera à TelePromento sur RAI 1 pendant L'héritage, programme dirigé par Flavio Insinna de 18.45h20.00 à XNUMXhXNUMX.
Innovant à tous égards, avec un design unique et capable de protéger la santé et l'environnement, X-BIO Circulife est le premier matelas de la gamme produit à partir de bouteilles en plastique recyclées. Un nouveau produit tourné vers un monde plus durable, vers le bien-être de la personne et vers l'avenir de la planète et des générations futures.
À cet égard, donc, avec une publicité faisant explicitement référence au site Web, X-bio.it, il n'y avait pas d'autre possibilité que d'optimiser les serveurs et les piles logicielles afin de résister au pic de trafic d'un programme sur la première chaîne nationale et vu par des millions de personnes.
Préoccupations et préparatifs côté serveur et Hébergement moins de deux heures après le lancement.
Il faut dire pour être juste que nous n'avons pas eu beaucoup de temps pour tout préparer, en effet c'était plutôt improvisé puisque nous n'avons pas été prévenus longtemps à l'avance mais seulement deux heures avant la diffusion du 7 novembre.
Lorsque nous avons parlé avec le développeur qui s'inquiétait de la rapidité du site et de la diffusion prochaine dans moins de deux heures, notre premier commentaire était quelque chose comme ceci :
Vous serez inévitablement déconnecté. Sans si ni mais. Pour ces événements, nous nous préparons au moins une semaine à l'avance.
Cependant, la chose laissée ainsi sonnait mal. Très mauvais, plus pour nous que pour eux. Nous ne pouvions pas laisser le site se déconnecter au milieu de cet événement, et ce n'était pas cool non plus, après avoir documenté un article le mois précédent intitulé Comment ne pas passer à la télé avec votre site WooCommerce s'il n'est pas correctement configuré côté Serveur et Hébergement.
C'est normal que dans ce cas, le site soit un e-commerce construit dans Prestashop et non WooCommerce, mais cela n'a pas beaucoup changé.
Nous avions deux heures à notre disposition. Peu, très peu, mais pas très peu.
Quoi que nous fassions, ce serait fait avec certitude et très, très vite.
Évidemment, les données d'Auditel devaient être prises en compte, étant donné que le Legacy a récolté l'une des parts les plus élevées de tout le lundi avec 4.39 millions de spectateurs et une part de 25.4%.
Qu'aurions-nous pu faire, étant donné que l'hébergement Prestashop et le site fonctionnaient déjà sur un serveur dédié AMD Ryzen 3600 avec 6 cœurs / 12 threads - 64 Go de RAM et deux disques nVME en RAID1 et une liaison montante de 1 Gbit/s ?
Nous n'aurions certainement pas eu le temps de commander une machine avec plusieurs cœurs et threads, nous n'aurions pas eu plus de temps pour commander une liaison montante 10Gbit/s et une carte réseau 10Gbit, aussi parce que la machine devait être commandée, installée , configuré, migré, 4 heures au mieux, pas deux.
Par conséquent, nous nous sommes "limités" à changer rapidement de serveur de noms de Godaddy à CloudFlare cela nous aurait permis d'absorber le pic de trafic des images multimédia, jpeg, png, css et js, ainsi que configurer le serveur avec une configuration avancée incluant un Full Page Cache côté serveur comme Varnish.
Parce que bien qu'il soit communément admis que CloudFlare met en cache html, il est bon de se rappeler que CloudFlare ne met pas en cache HTML par défaut, à moins que vous ne passiez à des forfaits payants coûteux et que vous fassiez une configuration de points limitée et délicate par rapport à ce que vous pouvez faire élégamment en quelques minutes et gratuitement avec Varnish
Le site a très bien tenu sans down et sans ralentissements avec un étonnement extrême, surtout le nôtre. Malheureusement, vu l'urgence et les délais très serrés, nous n'avons pas eu la possibilité de documenter l'événement comme nous l'aurions souhaité, cependant, nous nous sommes promis que nous serions refaits avec un meilleur reportage et documentation dans la diffusion télévisée du lendemain.
Préparez-vous mieux pour la durée du téléachat de toute la semaine du 7 au 11 novembre.
Conscients que le lancement durerait encore 4 jours, nous avons souhaité améliorer encore l'infrastructure en utilisant, tout d'abord, un matériel beaucoup plus puissant. En fait, nous sommes passés de 6core / 12 threads à 16core / 32 threads, triplant effectivement le nombre de threads disponibles, certes utiles et potentiellement décisifs pour le spawn des processus PHP-FPM et pour les threads Percona Server (un fork de MySQL).
Dans tout cela nous avons évidemment revu le réglage du serveur web, le SGBD, PHP-FPM, afin de trouver le meilleur compromis entre vitesse et multithreading, en évitant les charges excessives et les blocages éventuels au niveau de la BD.
Le tout a été fait avec une approche commerciale qui est aussi assez intéressante, à savoir celle de louer gratuitement la voiture pour l'heure prévue. On ne peut pas entrer dans les détails sur le sujet, mais il suffit de savoir que pour de telles situations, par exemple, on peut louer une voiture pour 500 euros/mois tout à fait gratuitement sans facturer un seul centime au client final, si ce n'est le coût d'installation/de migration et conseil en systèmes.
Non seulement Stack Server, mais également les implémentations d'applications sur Prestashop.
Bien que la partie serveur ait été extrêmement facile à mettre en œuvre, la partie application logicielle aurait plutôt eu une modification nécessaire du côté de l'application par le développeur. Car s'il est vrai que données en main, Prestashop s'avère être un meilleur CMS orienté ecommerce à bien des égards, notamment en termes de performances, par rapport à WooCommerce, il est également vrai que Prestashop ne se prête pas bien à travailler avec du scaling et du cache comme Vernis.
Vous pouvez utiliser Varnish par défaut, mais vous risquez alors que l'utilisateur ne puisse pas se connecter ou effectuer un achat, ce qui n'a aucun sens d'un point de vue purement commercial.
Nous avons donc dû insérer une routine lors de la phase de connexion qui créerait un cookie pour identifier un utilisateur connecté et lui permettre de naviguer dans son espace client, avec ses données et sans risquer d'être déconnecté.
S'il est relativement facile de faire fonctionner Prestashop avec Varnish, il n'est pas aussi facile de le faire BIEN fonctionner.
Comment s'est passé le nouveau serveur ? Jugez par vous-même.
Nous pourrions donner des chiffres, parler des charges, de la vitesse des requêtes, du taux d'accès au cache et de bien d'autres choses. Cependant, ce qui est le plus important pour le visiteur final, c'est de trouver un site disponible, rapide et accrocheur lorsque Flavio Insinna nomme le nom du site et non une erreur 500 due à un épuisement des ressources, une Bad Gateway, ou un site qui charge la première page en 16 (seize) secondes, comme nous avons eu l'occasion de mesurer et de documenter sur le cas précité « Comment ne pas passer à la télé ».
Par conséquent, en plus de dire que le serveur a très bien résisté, travaillant toujours abondamment dans la zone de confort (pour nous, la zone de confort est de 50% du nombre de threads), c'est-à-dire par rapport à 32 threads, où une charge moyenne de 32 correspond à 100%, on considère la zone confortable à moins de 16 de la charge Moyenne.
Nous avons utilisé Camtasia Studio pour enregistrer l'intégralité de l'événement en "live", regarder la diffusion en direct sur Ray Play puis simultanément aller voir ce qui se passait sur le terminal au niveau du chargement, et sur le navigateur Microsoft Edge pour simuler la navigation d'un l'utilisateur normal vient de terminer la publicité.
Vous pouvez voir la vidéo et l'analyse vidéo avec les écrans de serveur, les tests de charge, de pool et de vitesse du site et du TTFB directement dans cette vidéo, créée afin de documenter comment vous pouvez également passer à la télévision sans plantage ni temps d'arrêt ni avoir à dépenser des quantités insensées sur des technologies douteuses telles que le Cloud, le cluster ou similaire. Toujours en rappelant que chaque cas est toujours un cas en soi, et pas forcément cette solution pour ce cas, convient à tous les besoins des sites à fort trafic.
