Table des matières de l'article :
Avec cet article, nous souhaitons retracer l'histoire d'un vendeur en ligne de couches écologiques « assez connu » qui génère environ 20 000 visiteurs uniques par mois et environ 300 000 pages vues par mois.
Bref, d'un point de vue purement systémique, le trafic n'est en aucun cas élevé, bien que plus que suffisant au niveau entrepreneurial pour générer des profits importants.
Cependant, l'ancien hébergeur avait d'importants problèmes de performances de navigation qui, dans certains cas, rendaient le site Web absolument impossible à enregistrer avec des erreurs de délai d'attente et de mauvaises passerelles.
Une erreur 502 Bad Gateway sur Magento signifie qu'un délai d'attente a été dépassé lors de l'attente d'une réponse HTML de l'interpréteur PHP exécuté derrière le serveur web NGINX.
Cela peut avoir plusieurs raisons, mais la principale raison est essentiellement que PHP est incapable de terminer l'exécution de son code et de renvoyer une sortie au serveur Web.
Le problème est-il dans la lenteur du code ? Le problème vient-il de la lenteur de la voiture ? Un sous-dimensionnement du matériel ? Une survente de ressources ?
Essentiellement, toutes les raisons peuvent être vraies, mais certainement ce qui intéresse un entrepreneur n'est pas tant de comprendre à quoi est attribuable la cause mais que le site Web est en ligne et génère des ventes, donc des profits, donc des profits.
Lors de la connexion au panneau de contrôle cPanel de l'ancien hébergeur, la première chose que nous remarquons est la forte consommation de processeur de pointe, qui atteint près de 200 % de la charge maximale autorisée.
En consultant la colonne complète ci-dessous, nous constatons que cette valeur est largement dépassée depuis plusieurs jours et que le problème n'est donc pas dû à un pic de visites, à des analyses, à un robot malveillant ou à un crawler, mais simplement à une norme absolument inadéquate qui compromet la navigation normale des clients potentiels et l'exploration du contenu par les moteurs de recherche comme Google, pénalisant ainsi le référencement naturel.
Concrètement, on peut lire qu'au cours des dernières 24 heures, le temps d'utilisation du CPU est d'environ 60000 contre les 20000 autorisés, ce qui est exactement le triple.
Mais qu'est-ce qui fait que faire fonctionner un commerce électronique Magento comme celui-ci soit si lent et si avare de ressources comme le processeur ?
Plusieurs questions se posaient à ce sujet, mais après quelques conjectures et en tenant compte de cas similaires antérieurs avec le même fournisseur, nous avons jugé approprié de changer d'hébergement et de tout migrer vers nos systèmes.
Nous avons donc opté pour une configuration sur un serveur d'entrée de gamme équipé de Linux CentOS 7 , qui peut garantir non seulement une résolution rapide du problème de charge, mais aussi une vitesse d'exécution optimale, une triple sauvegarde, un système de surveillance des ressources tel que ZABBIX et une protection DDOS de couche 3 et de couche 7.
La migration s'est déroulée en différentes phases complétées par le placement hors ligne du site principal et le pointage du DNS vers la nouvelle configuration, avec un réel down perçu d'environ 5 minutes pour s'assurer que le ecommerce n'est pas passé en mode split et donc paiements enregistrés et vous commandez à la fois sur l'ancien et le nouvel hébergement.
Le serveur a été équipé du noyau 5.0 et de TCP BBR pour obtenir des améliorations réseau même pour les connexions smartphone 3G non optimales, un réglage MySQL adéquat, HTTP/2 et diverses virtuosités techniques qui font partie de notre « recette secrète ».
Consommation CPU après migration sur nos systèmes.
Après avoir migré le site vers nos systèmes, nous avons décidé d'évaluer la charge du processeur afin de déterminer s'il y avait réellement une amélioration globale et d'intervenir éventuellement (si cela ne suffisait pas) avec un profilage avec New Relic APM pour comprendre en détail ce qui n'allait pas au niveau de l'application.
Comme on l'avait plutôt supposé dans la phase initiale, le problème n'était pas d'application mais plutôt au niveau de la configuration et du dimensionnement du matériel.
En fait, la charge CPU le premier jour d'hébergement sur nos systèmes n'a jamais dépassé 10 % même face aux opérations planifiées telles que la sauvegarde de la base de données et les fichiers physiques.
Ci-dessous, vous pouvez voir la charge des dernières 24 heures, ou plutôt de 2h30 lorsque l'agent Zabbix a été installé jusqu'au moment où l'article a été écrit.
Bien que ce ne soit pas très clair pour ceux qui n'ont pas l'habitude de lire les graphes ZABBIX, la zone verte représente le temps CPU en temps d'inactivité, c'est-à-dire non occupé et la ligne bleue (difficile à voir même à l'œil nu) Consommation CPU qui selon la légende a une valeur moyenne de 0,85% et une valeur maximale de 6%.
Comment se fait-il que dans l'autre hébergement la consommation CPU était de 60000 sur 20000 ou une consommation standard réelle de 300% ?
Encore une fois, il ne nous appartient pas de répondre à ces questions, mais seulement de démontrer que la solution aux problèmes de charge existe et nous sommes généralement l'une des solutions les plus populaires pour les entrepreneurs, les référenceurs et les développeurs qui décident de faire des affaires rentables en ligne et non il suffit de garder en ligne un site lent et angoissant qui n'apporte aucun profit.
Avoir un Hébergement Magento Performant, c'est offrir au client la possibilité de maximiser ses profits. Il n'y a pas de dépenses, seulement des investissements.
