Éviter les désastres du CMS : comment éviter les temps d'arrêt du site Web

Qu'est-ce que cela signifie concrètement pour qu'un site soit considéré comme indisponible ?

Souvent, cela dépend de qui vous demandez.

Pour qu'un site Web soit considéré comme indisponible, cela peut signifier un certain nombre de choses différentes :

• Le site est totalement indisponible.
• Le site Web est en ligne mais inutilisable lent.
• Le site Web affiche des messages d'erreur pour certains utilisateurs ou emplacements.
• Le site Web fonctionne pour la plupart des visiteurs, mais certains ne peuvent tout simplement pas se connecter à leur CMS, par exemple pour créer, modifier ou publier du contenu.

Quelle que soit la cause ou le degré, l'impact de l'indisponibilité d'un site Web peut être grave, qu'il s'agisse de commandes de commerce électronique perdues, d'utilisateurs frustrés ou d'une perte de confiance des clients.

Dans la troisième de notre série Éviter les catastrophes CMS , nous explorons les causes profondes classiques des temps d'arrêt des sites Web et le rôle que la surveillance continue et d'autres facteurs jouent pour éviter cela.

Premièrement, le rôle que joue la surveillance continue

Nous surveillons différents aspects d'un site Web, afin que nous puissions savoir quand quelque chose ne fonctionne pas correctement à l'une des différentes couches qui composent notre plate-forme WordPress VIP entièrement gérée. Ces couches incluent :

• Connectivité réseau
• Équilibreurs de charge
• Serveurs Web
• Mise en cache d'objets (Memcached)
• Bases de données
• Recherche élastique
• Service de fichiers (CDN)

Nous essayons de détecter rapidement les problèmes afin de pouvoir anticiper les problèmes futurs susceptibles d'affecter la stabilité du site Web. Les journaux de références croisées de différents composants du système nous permettent d'examiner les périodes pendant lesquelles un site Web a été signalé comme instable. Étant donné qu'une combinaison de facteurs plutôt qu'un seul problème peut être responsable des temps d'arrêt, nous utilisons un certain nombre d'outils pour comparer les données entre les systèmes et les applications.

Dans la plupart des cas, l'instabilité du site Web est le résultat du code d'application, c'est-à-dire d'un thème WordPress personnalisé ou tiers et d'un code de plug-in. Voici quelques éléments que nous recherchons lorsque nous enquêtons sur un site instable et comment les atténuer.

Pas assez de cache

La chose la plus importante que vous puissiez faire pour vous assurer qu'un site est performant et stable est de vous assurer que toute page complète pouvant être mise en cache est mise en cache. Les pages non mises en cache doivent être créées sur le serveur chaque fois qu'elles sont demandées, ce qui est un processus plus lent et plus sujet aux erreurs.

La réponse WordPress VIP :

WordPress VIP Platform fournit une puissante mise en cache des pages via un réseau mondial de serveurs de cache de périphérie, chacun utilisé pour stocker et servir le contenu le plus proche d'un utilisateur final. Le temps de réponse d'un serveur de cache périphérique est presque toujours beaucoup plus rapide que tout ce qui contourne la mise en cache des pages et atteint les serveurs d'origine.

Défis de mise en cache

Parce qu'ils exigent une expérience personnalisée et entièrement interactive, certains sites, en particulier ceux de commerce électronique, ne peuvent tout simplement pas être mis en cache au niveau du cache de page.

Souvent, un compromis peut être trouvé dans lequel une page statique est servie par le cache périphérique, avec des fonctionnalités dynamiques (par exemple, le statut de connexion, les paniers d'achat) ajoutées via JavaScript. Les requêtes asynchrones de JavaScript peuvent ensuite être utilisées pour communiquer avec un point de terminaison de l'API REST WordPress conçu avec une charge beaucoup plus faible qu'un chargement de page complet.

Alternativement, c'est là que la mise en cache d'objets entre en jeu. La page peut rester dynamique, mais des parties de la page et toutes les données utilisées peuvent être stockées et récupérées dans le cache d'objets pour éviter d'avoir à interroger la base de données.

La réponse WordPress VIP :

Chaque environnement d'application WordPress VIP possède son propre cluster Memcached dédié, qui stocke les données de cache d'objets en mémoire pour une récupération rapide et efficace comme l'éclair.

Déploiements de code non testés

Il s'agit d'un autre coupable courant de l'indisponibilité du site Web et assez facile à diagnostiquer, basé sur la cause et l'effet purs.

Si votre site Web vient de déployer du code non testé, entraînant des problèmes de site immédiats, il y a probablement votre cause. Si vous le pouvez, rétablissez le code suspect à la version précédente dès que possible.

La meilleure chose à faire pour éviter cette situation ? Testez minutieusement chaque élément de code sur un environnement de développement ou de préproduction distinct avant de le mettre en production.

La réponse WordPress VIP :

Étant donné que tous nos déploiements de sites se font via GitHub, les clients WordPress VIP peuvent facilement annuler eux-mêmes le code, sans perdre les nouvelles modifications de code, qui restent stockées en toute sécurité dans l'historique des révisions GitHub. En option, dans des situations d'urgence, nous pouvons restaurer le site Web d'un client vers un déploiement précédent en son nom, indépendamment de GitHub.

En ce qui concerne les environnements, toutes les applications hébergées sur notre service entièrement géré peuvent avoir un environnement de développement ou de staging séparé. La synchronisation des données depuis la production est facile, vous permettant de tester le code par rapport à la même quantité et au même type de données que sur votre site Web de production.

Erreurs PHP

WordPress utilise du code PHP sur le serveur. Une erreur PHP peut être "fatale", ce qui signifie qu'une fois l'erreur survenue, la page Web, le script ou la commande cessera de s'exécuter. Celles-ci apparaîtront presque toujours comme des erreurs visibles quelque part et seront enregistrées dans les journaux PHP.

Remarque : certains avertissements PHP dans PHP 7 deviennent des erreurs fatales dans PHP 8, il est donc important de prendre ces erreurs au sérieux.

La réponse WordPress VIP (plus des conseils utiles) :

Notre plateforme enregistre automatiquement toutes les erreurs PHP, les rendant disponibles aux clients WordPress VIP dans leur tableau de bord et à nos ingénieurs.

Conseil de pro : traitez et corrigez toutes les erreurs PHP, même si un site semble fonctionner correctement. Régulièrement, nous voyons des journaux remplis d'erreurs PHP, voire fatales, sur un site qui semble stable. Cependant, cela ne signifie pas nécessairement que le site fonctionne correctement . Garder les journaux PHP clairs en traitant les erreurs mineures et les avertissements facilite la recherche d'erreurs plus graves lors du débogage.

Requêtes de base de données MySQL lentes

Chaque site Web WordPress utilise une base de données pour stocker le contenu du site Web et les données de configuration. Les requêtes de base de données récupèrent ces données de contenu pour les pages Web, mais parfois ces requêtes sont écrites de manière inefficace. Ils peuvent fonctionner correctement pour les sites ne contenant que quelques centaines de pages, mais se bloquer lors du traitement de grandes quantités de données (certains sites Web de notre plate-forme ont des millions d'enregistrements stockés).

Une requête lente monopolise les ressources de la base de données, ce qui peut avoir un impact sur la stabilité du site, non seulement pour la page, le script ou la commande exécutant le SQL, mais pour l'ensemble de l'application. Les sites ont souvent du mal parce que les requêtes de base de données simples ou multiples sont lentes, par exemple, toute requête qui prend plus de 0,75 seconde à s'exécuter.

La réponse WordPress VIP :

WordPress VIP aide à atténuer les goulots d'étranglement de la base de données en fournissant à chaque application un cluster de base de données dédié comprenant une base de données principale, où se produisent toutes les requêtes d'écriture de base de données, et une ou plusieurs bases de données répliquées en lecture seule. Cela augmente le nombre de requêtes de base de données simultanées qui peuvent avoir lieu, répartissant la charge des ressources lorsqu'un site est sous pression. Cela dit, les requêtes de base de données lentes ne peuvent pas toujours être résolues simplement en ajoutant des ressources de base de données supplémentaires. C'est pourquoi nous conseillons aux clients de surveiller les requêtes de base de données lentes en utilisant Query Monitor et New Relic (fournis par notre plate-forme). Celles-ci mettent en évidence l'origine des requêtes dans la base de données, afin que votre équipe de développement puisse les refactoriser pour optimiser les performances.

Enfin, notre assistance applicative et nos ingénieurs Premier peuvent également aider votre équipe à trouver et analyser ces requêtes, et suggérer des moyens de les améliorer pour plus de rapidité et d'efficacité.

Ecritures excessives dans la base de données

Parfois, une fonctionnalité, telle que la journalisation personnalisée ou le code de suivi, met à jour la base de données à chaque demande. Cela peut entraîner une instabilité pour deux raisons :

• Répliques de base de données précédentes : toutes les requêtes en écriture sont dirigées vers la base de données principale ; les requêtes de base de données ultérieures pour la même table (ou les mêmes tables) dans la même demande de page y seront également dirigées. En ne profitant pas des répliques de base de données, cela limite l'évolutivité du site.
• Contournement de la mise en cache des pages : pour qu'une écriture de base de données se produise à chaque demande de page, la mise en cache des pages doit être contournée. Mais cela signifie que la première (et la meilleure) ligne de défense a été compromise.

La réponse WordPress VIP :

Dans ces circonstances, nous vous conseillons de refactoriser la fonctionnalité. Par exemple, l'analyse de contenu est généralement mieux déléguée à un service externe qui utilise un extrait de code JavaScript dans la page plutôt qu'un code côté serveur, ce qui ne fonctionne pas bien avec la mise en cache et peut entraîner des écritures excessives dans la base de données.

Autres causes connues de temps d'arrêt et comment les éviter

Plugins

Il existe des milliers de plugins tiers populaires et utiles dans l'écosystème WordPress qui offrent des fonctionnalités et des fonctionnalités fantastiques. Certains, cependant, ont des difficultés à évoluer, ce qui peut entraîner des problèmes de temps d'arrêt lorsqu'ils sont ajoutés à un site Web avec des tonnes de contenu et de trafic.

La réponse WordPress VIP :

En tant que bons intendants de l'écosystème, nous contactons régulièrement les fournisseurs avec des suggestions pour améliorer leurs performances dans les environnements à fort trafic. Nous pouvons également suggérer des plugins alternatifs qui ont été essayés et testés à grande échelle sur notre plateforme.

Journalisation personnalisée

La journalisation personnalisée est un outil de débogage puissant, souvent la seule méthode viable pour traquer un bogue ou un problème qui semble se produire uniquement sur un site de production. À de nombreuses reprises, cependant, nous avons vu une journalisation personnalisée intégrée à PHP sur un site à fort trafic ralentir les choses ou mettre un site en danger de temps d'arrêt en raison d'écritures excessives dans la base de données.

La réponse WordPress VIP :

Pour les clients, nous fournissons un accès aux journaux PHP standard dans le panneau Santé du tableau de bord de l'application WordPress VIP. Là, ils peuvent enregistrer des erreurs personnalisées (et également dans New Relic), ce qui n'aura pas d'impact négatif sur la base de données.

Appels d'API à distance

Certains sites Web tirent parti des appels d'API REST côté serveur vers d'autres applications ou services. Celles-ci sont assez rapides dans des circonstances normales, mais parfois le code d'application sous-jacent entraîne une réponse lente, expire ou génère une erreur.

La réponse WordPress VIP :

Pour minimiser ces problèmes, nous conseillons un "codage défensif". Cela dépend de l'objectif de l'appel à distance, mais souvent, lorsqu'une requête à distance échoue, il est possible de se rabattre sur une réponse mise en cache d'une requête précédente, ou au moins de "gérer l'erreur avec élégance", afin que le reste de la page puisse charge encore. Nous fournissons un certain nombre de fonctions d'assistance pour gérer ces scénarios. Garder un délai d'attente faible signifie également que les ressources PHP sont libérées plus rapidement si l'API distante ne répond pas.

En savoir plus dans notre série Éviter les catastrophes CMS

Lorsque votre entreprise est en jeu, vous ne pouvez pas vous permettre d'envoyer de nouvelles affaires ailleurs et de ternir votre marque en faisant en sorte que votre système de gestion de contenu (CMS) offre une mauvaise expérience numérique. Dans Comment améliorer les performances du site Web , nous diagnostiquons cinq coupables courants de ralentissement et comment accélérer les choses à l'aide d'un CMS agile.

Les journées à fort trafic devraient être un motif de célébration, et non un cauchemar pour les ingénieurs qui essaient de maintenir un site et des applications en état de marche et de bourdonnement pour gérer la charge, et votre réputation intacte. Dans Scaling WordPress for High Traffic , nous explorons quatre approches pour permettre à un site Web WordPress de gérer ces raz-de-marée de trafic.