27 mai 2022

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

Comment optimiser les requêtes les plus difficiles sur WordPress ?

Bannière SQL

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)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  à 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.

Vous avez des doutes ? Vous ne savez pas par où commencer ? Contactez-nous !

Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

Managed Server Srl est un acteur italien leader dans la fourniture de solutions système GNU/Linux avancées orientées vers la haute performance. Avec un modèle d'abonnement peu coûteux et prévisible, nous garantissons que nos clients ont accès à des technologies avancées en matière d'hébergement, de serveurs dédiés et de services cloud. En plus de cela, nous proposons des conseils système sur les systèmes Linux et une maintenance spécialisée en SGBD, sécurité informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'hébergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapté aux administrations publiques, aux PME et à toutes tailles.

Red Hat, Inc. détient les droits de Red Hat®, RHEL®, RedHat Linux® et CentOS® ; AlmaLinux™ est une marque commerciale d'AlmaLinux OS Foundation ; Rocky Linux® est une marque déposée de la Rocky Linux Foundation ; SUSE® est une marque déposée de SUSE LLC ; Canonical Ltd. détient les droits sur Ubuntu® ; Software in the Public Interest, Inc. détient les droits sur Debian® ; Linus Torvalds détient les droits sur Linux® ; FreeBSD® est une marque déposée de la FreeBSD Foundation ; NetBSD® est une marque déposée de la Fondation NetBSD ; OpenBSD® est une marque déposée de Theo de Raadt. Oracle Corporation détient les droits sur Oracle®, MySQL® et MyRocks® ; Percona® est une marque déposée de Percona LLC ; MariaDB® est une marque déposée de MariaDB Corporation Ab ; REDIS® est une marque déposée de Redis Labs Ltd. F5 Networks, Inc. détient les droits sur NGINX® et NGINX Plus® ; Varnish® est une marque déposée de Varnish Software AB. Adobe Inc. détient les droits sur Magento® ; PrestaShop® est une marque déposée de PrestaShop SA ; OpenCart® est une marque déposée d'OpenCart Limited. Automattic Inc. détient les droits sur WordPress®, WooCommerce® et JetPack® ; Open Source Matters, Inc. détient les droits sur Joomla® ; Dries Buytaert détient les droits sur Drupal®. Amazon Web Services, Inc. détient les droits sur AWS® ; Google LLC détient les droits sur Google Cloud™ et Chrome™ ; Facebook, Inc. détient les droits sur Facebook® ; Microsoft Corporation détient les droits sur Microsoft®, Azure® et Internet Explorer® ; La Fondation Mozilla détient les droits sur Firefox®. Apache® est une marque déposée de The Apache Software Foundation ; PHP® est une marque déposée du groupe PHP. CloudFlare® est une marque déposée de Cloudflare, Inc. ; NETSCOUT® est une marque déposée de NETSCOUT Systems Inc. ; ElasticSearch®, LogStash® et Kibana® sont des marques déposées d'Elastic NV. Ce site n'est affilié, sponsorisé ou autrement associé à aucune des entités mentionnées ci-dessus et ne représente aucune de ces entités de quelque manière que ce soit. Tous les droits sur les marques et noms de produits mentionnés sont la propriété de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnées appartiennent à leurs titulaires. MANAGED SERVER® est une marque déposée au niveau européen par MANAGED SERVER SRL Via Enzo Ferrari, 9 62012 Civitanova Marche (MC) Italie.

JUSTE UN MOMENT !

Souhaitez-vous voir comment votre WooCommerce fonctionne sur nos systèmes sans avoir à migrer quoi que ce soit ? 

Entrez l'adresse de votre site WooCommerce et vous obtiendrez une démonstration navigable, sans avoir à faire absolument quoi que ce soit et entièrement gratuite.

Non merci, mes clients préfèrent le site lent.
Retour en haut de page