Nous voulons documenter avec cet article l'histoire d'un vendeur "assez connu" de couches écologiques en ligne qu'il génère environ 20 mille visiteurs uniques par mois et sur 300 mille 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.
Un 502 Bad Gateway sur Magento, cela signifie qu'un délai d'attente a été atteint pour attendre 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.
Connexion au panneau de configuration cPanel de l'ancien Hoster, la première chose que nous remarquons est le pic élevé de consommation CPU, qui atteint près de 200% de la charge maximale autorisée.
Concrètement, en vérifiant la colonne complète ci-dessous, nous voyons que cette valeur est une valeur qui est pratiquement dépassée depuis des jours, et que donc le problème n'est pas dû à un pic (un pic) de visites, à certains scans, à certains bots ou des robots malveillants, mais simplement un standard absolument inadéquat qui compromet la navigation normale des clients potentiels et certainement aussi le crawl de contenu par les moteurs de recherche tels que Google, donc pénalisant aussi au niveau SEO.
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 ?
Il faudrait se poser plusieurs questions à ce sujet mais "deviner" et prendre en considération cas précédents très similaires avec le même fournisseur nous avons pensé qu'il était approprié de varier l'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 assurer 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 Layer 3 et Layer 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 était équipé de Kernel 5.0 e BBR TCP pour obtenir des améliorations au niveau du réseau même pour des connexions de smartphones 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.
Dans la post migration du site sur nos systèmes nous avons décidé d'évaluer la charge CPU pour réellement comprendre s'il y avait une amélioration de l'ensemble et éventuellement intervenir (si cela ne suffisait pas) à un profilage avec Nouvelle relique 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.
