Optimisation des performances de WordPress Partie 1 : Connaître vos requêtes de base de données

Il existe de nombreuses mauvaises habitudes que les développeurs WordPress devraient éviter. Certains d'entre eux incluent l'utilisation de l'astérisque (*) par requête SELECT  , des requêtes redondantes et, surtout, une mauvaise connaissance de SQL.

Après des années de développement sur des sites Web d'entreprise, les développeurs se posent souvent les questions suivantes :

• Pourquoi ne connaissais-je pas cette méthode avant ?
• Comment aurais-je pu m'en passer avant ?

La plupart des développeurs travaillant sur WordPress reconnaîtront que WordPress a :

• Problèmes d'optimisation constants
• Problèmes d'évolutivité pouvant entraîner des temps d'arrêt du site
• Plugins tiers qui créent des charges de base de données élevées

Il est courant pour un développeur WordPress de limiter le nombre de plugins installés et activés sur leur site internet. La surcharge qu'un mauvais plugin peut infliger à un site Web est inimaginable. Lorsque vous comptez sur des plugins tiers, les performances de votre site Web sont à la merci de ces développeurs tiers. Si vous ne comprenez pas le code du plug-in, celui-ci peut contenir une requête inefficace susceptible de bloquer votre site Web. Les plugins inefficaces sont particulièrement difficiles à traquer, et cela peut prendre des semaines pour comprendre la cause du ralentissement de votre site.

Le sujet de l'optimisation des performances peut être un sujet très large à couvrir. Au lieu de tout aborder en même temps, je vais essayer de m'attaquer à une requête de pagination qui a créé des problèmes d'évolutivité pour de nombreux développeurs WordPress. C'est une requête que nous voyons souvent lors du développement sur un site WordPress.

Au lieu de donner la solution immédiatement, faisons cet exercice ensemble.

Prenez un moment et identifiez 10 éléments que vous pouvez optimiser pour la requête suivante :

SELECT SQL_CALC_FOUND_ROWS wp_posts.*, wp_postmeta.*
DE wp_posts INNER JOIN wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id)
INNER JOIN wp_term_relations ON (wp_posts.ID = wp_term_relationsships.id_objet)
OÙ 1=1 ET ( wp_term_relationsships.term_taxonomy_id DANS (554) ) 
ET wp_posts.post_type = 'Publier' 
ET (wp_posts.post_status != 'ébauche' || wp_posts.post_status <> 'privé' || wp_posts.post_status != 'déchets')
ET DISTRIBUER(wp_postmeta.méta_valeur AS CHAR) = 'épisodes'
GROUPER PAR wp_posts.ID ORDER BY wp_posts.post_date DESC LIMITE 0, 10;
SÉLECTIONNER FOUND_ROWS();

Voici une meilleure approche :

• • 1. wp_posts.* => wp_posts.post_title, wp_posts.post_content, wp_posts.post_name, wp_posts.post_date, wp_postmeta.meta_key, wp_postmeta.meta_valueIndiquez uniquement les colonnes dont vous avez besoin. Plus vous avez de colonnes répertoriées, plus votre objet mémoire devient grand.
  • 2. O 1 = 1 sera toujours vrai. Il s'agit d'une clause redondante. J'ai toujours suivi la philosophie de garder les choses courtes et simples ! Suivez le principe KISS. Si vous construisez une clause OÙ à la volée et ne savez pas si vous avez besoin d'expressions supplémentaires dans la clause Où un 1 = 1 à la fin, il garantit que vous allez créer une clause WHERE pour que la déclaration SELECT  n'explose pas.
  • 3. wp_term_relationships.term_taxonomy_id DANS (554)Pour cette déclaration spécifique, une seule taxonomie est incluse. Utilisation directe dites '='  est le meilleur pour la performance, suivi de DANS.  S'il y a plus de 2 taxonomies à appeler, utilisez  IN . OR est le plus lent.
  • 4. (wp_posts.post_status! = 'brouillon' || wp_posts.post_status <> 'privé' || wp_posts.post_status! = 'poubelle')! = ET <> ils sont tous les deux terribles pour les performances, vous pouvez obtenir les mêmes résultats en utilisant wp_posts.post_status = 'publier' .
  • 5. CAST (wp_postmeta.meta_value AS CHAR) = 'épisodes'C'est compliqué car méta_valeur c'est un mec LONGTEXTE et n'est pas indexé par le schéma de la base de données. L'utilisation de ce couple clé/valeur est légèrement plus lourde en ressources que la méta_clé o post_id dans la table wp_postmeta .
  • 6. GROUPER PAR wp_posts.IDL'utilisation de PAR GROUPE peut nécessiter des performances élevées. Imaginez l'algorithme de tri qui doit être fait pour obtenir le jeu de données de retour correct.
  • 7. COMMANDER PAR wp_posts.post_date DESC.ASC est la clause COMMANDÉ PAR défaut. Le DESC il s'agit essentiellement d'inverser l'ordre chronologiquement, nécessitant l'exécution d'un algorithme supplémentaire.
  • 8. LIMIT 0, 10L'utilisation de la méthode décalage peut être mauvais pour les performances. MySQL est généralement inadéquat pour compenser haute. Imaginez le scénario  LIMIT 200000, 10 . Cela peut être problématique lors de la pagination sur une table entière en stockant toutes les lignes en mémoire. Envisagez d'encapsuler la requête pour permettre au système de lire quelques lignes à la fois. Une solution consiste à utiliser un ID indexé à incrémentation automatique comme alternative.
  • 9. 'OU' il est modérément plus rapide en une fraction de seconde que '||'. Un autre avantage est la lisibilité. 
  • 10. SELECT FOUND_ROWS ()Exécution de requête inutile. Cela aurait pu être réalisé avec une seule requête efficace.

J'espère que vous avez apprécié cette première partie de la série de performances WordPress. Restez à l'écoute pour la deuxième partie.