Yann "Bug" Dubois

Développeur WordPress freelance à Paris
Flux RSS

Accélérer WordPress – Partie 2 – Le diagnostic

26 May 2009 Par : Yann Dubois Catégorie : Français, WordPress

Explosion de l\'utilisation du processeur sur le serveur webLe diagnostic

La stratégie d’optimisation d’un applicatif web quel qu’il soit passe par une première étape d’analyse et de bilan de la situation, nécessaire pour définir un plan d’action : dans un monde idéal, chacun disposerait d’un temps infini pour se consacrer aux détails. Dans la réalité pragmatique, toute stratégie s’inscrit dans une limite de moyens dont le temps fait partie. Le scénario proposé ici a nécessité environ deux journées de travail pour être mis en oeuvre sur trois blogs distincts hébergés sur le même serveur. Consacrer 48 heures à l’optimisation d’un site qui commence à monter en charge au point que les premiers problèmes de performances apparaissent semble un objectif raisonnable.

Comment savoir que ça dérape ?

Pour dresser le bilan, il faut évaluer l’ampleur des “dégâts” : nul besoin en effet de se lancer dans une optimisation si aucun problème tangible ne se manifeste; rappelons que sans aucune optimisation particulière, WordPress se comportera très correctement pour une audience modeste de quelques centaines à un millier de pages affichées par jour, que l’on soit sur un serveur dédié ou partagé.

Les indicateurs à surveiller particulièrement sont :

  • La vitesse d’affichage des pages telle que perçue par l’utilisateur, qu’on mesurera aisément avec l’extension “Firebug” de Mozilla par exemple. Les deux points principaux à surveiller sont le temps de chargement du fichier html “de base” de la page (qui devrait rester dans tous les cas inférieur à 2 secondes et la plupart du temps à une seconde), et le temps total de chargement de la page et de tous ses composants, qu’il serait sage de garder inférieur à 10 secondes pour un poids total de page inférieur à 800Ko (valeurs subjectives déterminées au pifomètres mais qui me semblent réalistes aujourd’hui en 2009 avec l’équipement moyen des internautes français qui tend vers le haut débit pour tous)
  • La vitesse d’exploration des pages par les robots crawlers Googlebot, qui est indiquée en temps “quasi réel” dans les Google Webmaster Tools (avec un décalage allant de 1 à 4 jours pour des sites francophones de taille moyene en général) : si le nombre de page explorées par Google baisse subitement, c’est souvent corrélé au fait que le temps de chargement des pages rencontré par les robots d’indexation devient exagérément long. Si vous en êtes là c’est qu’il y a un problème ! Moins de deux secondes est un chiffre correct, plus de 4 secondes deviennent problématiques, plus de 10 secondes et c’est rédhibitoire : vous risquez la sous-indexation, voire la désindexation de certaines de vos pages dans les moteurs de recherche.
  • La charge système du serveur d’hébergement (indiquée par des outils du type Munin et ses graphiques rrdtools), et notamment l’utilisation des ressources processeurs et de la mémoire : si leur utilisation moyenne au cours de la journée bondit subitement, c’est souvent qu’on a atteint un “seuil de performance” qui cause un goulet d’étranglement nuisible.
  • Le nombre de requêtes MySql qui passent en “slow query” (pour cela, il faut préalablement activer la journalisation des requêtes lentes dans le fichier de configuration de MySql). En principe, WordPress ne devrait pas générer du tout de requêtes de ce type. Dans les faits, une ou deux requêtes de quelques secondes chaque jour ne sont pas un drame. Si on atteint plusieurs par heure, par contre, il y a un problème, car c’est une partie importante de vos visiteurs qui sont certainement impactés par des ralentissements très perceptibles !

Toutes sortes d’outils et de méthodes sont disponibles pour creuser le diagnostic en cas de problèmes de performances constatés sur un ou plusieurs des 4 points ci-dessus (j’y reviendrais certainement en détail un jour dans un billet dédié !), mais ces quatre points de contrôles suffisent pour prendre une décision : si un ou plusieurs des points contrôlés posent problème, les mesures préconisées ci-dessous vont améliorer les choses.

Lire la suite : Première étape : Le grand ménage (partie 3/6)

A lire également...

WordPress › Error

There has been a critical error on your website.

Learn more about debugging in WordPress.