Les bases de données sont un élément important de votre site WordPress. La base de données de votre site contient des informations telles que : quel contenu est associé à quelle page, paramètres de plugin et de thème, utilisateurs et capacités de l’utilisateur, détails de la commande de ecommerce, etc. Bien que le code PHP indique à votre site comment fonctionner et que le CSS lui donne son apparence, la base de données contient toutes les informations que vous avez insérées dans votre site. La communication avec la base de données est donc une étape nécessaire pour générer une page pour vos utilisateurs !
Pourquoi l’optimisation des bases de données est-elle importante ?
En raison de son rôle dans la génération de pages sur votre site, la façon dont vous communiquez avec votre base de données est très importante. Les requêtes SQL utilisées pour obtenir et mettre à jour des informations dans votre base de données doivent être optimisées pour le faire aussi rapidement que possible. En optimisant à la fois les données de la base de données et les requêtes SQL communiquant avec celle-ci, vous améliorerez le temps de chargement de votre site, le délai jusqu’au premier octet et l’expérience globale de l’utilisateur.
Cache d’objet
L’une des options d’optimisation des performances proposées par WP Engine est la couche de mise en cache des objets. La mise en cache d’objets accélère la génération de votre page en stockant les résultats dans des requêtes répétées pour un accès plus rapide. Cette couche de cache stockera les requêtes encapsulées dans les fonctions wp_cache () définies par WordPress, ainsi que Transcients.
Comme la plupart du temps pour générer une page provient souvent de requêtes de base de données, utiliser le cache d’objet peut facilement améliorer les performances de nombreux sites. Pour activer la mise en cache des objets, sélectionnez votre nom d’installation dans le portail utilisateur et cliquez sur «Utilities» dans le menu de gauche. Il y aura une option pour activer ou désactiver le cache d’objets sur cette page.
Données autochargées
Dans WordPress, la base de données contient de nombreux paramètres de votre site. Ces paramètres peuvent inclure une liste de plugins actifs, votre thème actif, l’URL de votre site, les paramètres de thème, les paramètres de plugin, etc. La table wp_options de votre base de données est l’endroit où ces paramètres sont stockés. Parfois, les thèmes et les plugins aiment y stocker des éléments supplémentaires, comme Transients, de longues listes de règles de redirection et d’autres paramètres volumineux. Dans ce tableau se trouve une colonne intitulée «autoload» qui indique généralement à WordPress : ce paramètre doit-il être chargé sur chaque page par défaut ? Si la réponse est “oui” pour certains de ces paramètres extrêmement longs, il s’agit de données supplémentaires et d’octets que WordPress doit charger sur vos pages. Trop de contenus défini sur «autoload» entraîne un temps de passage au premier octet élevé et des performances de requête lentes en général.
Utilisez la requête ci-dessous pour savoir combien de données sont automatiquement chargées sur votre site et quelles lignes sont les plus longues :
SELECT LENGTH(option_value),option_name FROM wp_options WHERE autoload='yes'
ORDER BY length(option_value) DESC LIMIT 20;
Un autre conflit lors du chargement automatique d’une grande quantité de données survient spécifiquement lorsque le cache d’objets est activé. Le cache d’objets charge toutes les données à chargement automatique sur une seule ligne, et une quantité finie de données peut être stockée sur une ligne. Le cache d’objets rejettera la ligne comme étant trop grande lors du chargement d’une page, mais comme WordPress demande à ces données de charger une page, il la renvoie et provoque une boucle qui se termine par une erreur 502. Notre article sur le cache d’objets décrit plus en détail comment résoudre cette erreur spécifique.
Solutions de recherches
Si votre site compte des dizaines de milliers de messages, il est probable que les performances de recherche soient lentes avec la fonction de recherche WordPress normale. La raison en est double : premièrement, les requêtes de recherche dans votre base de données doivent examiner des millions de lignes pour renvoyer des résultats de recherche correspondants. De plus, la requête utilisée par défaut par WordPress n’a pas l’échelle voulue une fois que votre site a affiché quelques milliers de publications. La recherche peut prendre plusieurs secondes. Si plusieurs personnes effectuent une recherche simultanée sur votre site, les performances risquent d’être ralenties.
Dans cet esprit, si votre site contient des milliers de pages, de publications et de téléchargements, il est préférable d’utiliser une solution de recherche hors site, telle que ElasticPress ou Algolia. Cela supprime les contraintes liées à l’exécution de cette recherche vers un système séparé, entièrement optimisé pour la gérer, et cela permet d’obtenir de meilleurs résultats plus rapidement. Il y a aussi l’avantage supplémentaire de libérer plus de ressources de serveur pour gérer plus de trafic simultané, ce qui rend votre site plus évolutif.
Table de moteurs de stockage et mémoire
Dans MySQL, il existe deux principales tables de moteurs de stockage : MyISAM et InnoDB. La table de moteur de stockage utilisée par votre site peut faire une nette différence en termes de performances. WP Engine recommande toujours d’utiliser InnoDB Table Storage Engine, pour un motif valable. Le moteur MyISAM fonctionne parfaitement pour les opérations de lecture de base de données. Mais lorsqu’il s’agit d’écrire de nouvelles données ou de mettre à jour des données dans la base de données, MyISAM verrouille la table entière pendant cette opération d’écriture, ce qui signifie que d’autres écritures simultanées sur cette table sont verrouillées. Au contraire, InnoDB ne verrouille que la seule ligne en cours d’écriture. Cela rend MyISAM moins optimal pour les sites de production / live.
L’autre raison principale d’utiliser InnoDB en tant que table de moteur de stockage est liée à l’utilisation de la mémoire sur votre environnement de serveur. MySQL alloue un pool spécifique de mémoire appelé pool de mémoire tampon InnoDB à utiliser par les tables InnoDB. Les tables qui utilisent MyISAM ne peuvent pas utiliser ce pool de mémoire, ce qui signifie qu’elles écrivent automatiquement sur le disque (swap) au lieu de la mémoire normale sur le serveur.
Si vous ne savez pas quelle table de moteur de stockage est utilisé par vos tables de base de données, il suffit de le vérifier. Connectez-vous simplement à votre portail utilisateur et sélectionnez votre nom d’installation. Cliquez ensuite sur phpMyAdmin dans le menu de gauche. Sélectionnez votre base de données dans la liste de gauche et consultez la colonne Type. Si vous voyez des tables MyISAM dans la liste, vous pouvez facilement les remplacer par InnoDB. Cliquez simplement sur l’onglet SQL et exécutez la requête suivante pour chaque table MyISAM :
ALTER TABLE table_name ENGINE=InnoDB;Assurez-vous de remplacer nom_table par le nom de la table que vous souhaitez remplacer par InnoDB.
Nettoyage de la base de données
Un moyen rapide d’aider à nettoyer votre base de données consiste à rechercher des données «orphelines». MySQL est un système de «base de données relationnelles», ce qui signifie que les données d’une table seront souvent corrélées à celles d’une autre. Un bon exemple de l’aspect relationnel de votre base de données WordPress est de regarder les tables wp_posts et wp_postmeta. Dans wp_posts, chaque publication, page et image possède un identifiant dans la colonne intitulée « ID ». Dans wp_postmeta, cela correspond à la colonne « post_id », de sorte que des métadonnées spécifiques sont associées à des publications spécifiques. Nettoyer les données orphelines signifie supprimer les métadonnées associées à un ID de publication qui n’existe plus. Cliquez sur l’onglet SQL dans phpMyAdmin pour exécuter les requêtes suivantes et nettoyer les métadonnées orphelines.
Vérifiez si votre site contient des postmeta orphelins :
SELECT COUNT(pm.meta_id) as row_count FROM wp_postmeta pm LEFT
JOIN wp_posts wp ON wp.ID = pm.post_id WHERE wp.ID IS NULL;Effacez tous les postmeta orphelins :
DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts wp ON wp.ID =
pm.post_id WHERE wp.ID IS NULL;Vérifiez si votre site contient des commentmeta orphelins :
SELECT COUNT(*) as row_count FROM wp_commentmeta WHERE comment_id
NOT IN (SELECT comment_id FROM wp_comments);Effacez tous les commentmeta orphelins :
DELETE FROM wp_commentmeta WHERE comment_id NOT IN (SELECT
comment_id FROM wp_comments);Optimiser les tables
Utiliser régulièrement la commande Optimize Table est une bonne pratique pour améliorer les performances et la santé de la base de données. Optimiser les tables va recréer la table sélectionnée et supprimer tout espace disque excédentaire utilisé par cette table. En libérant l’espace disque utilisé, cela améliore les performances de votre site en réduisant la quantité de données à stocker en mémoire lors de l’accès aux tables.
Pour optimiser les tables, cliquez simplement sur votre nom d’installation dans le portail utilisateur et sélectionnez phpMyAdmin dans le menu de gauche. Choisissez ensuite votre base de données sur le côté gauche et cochez les cases en regard des tables que vous souhaitez optimiser. En bas, choisissez «Optimize» dans le menu déroulant.
article traduit de WP Engine : Database Optimization Best Practices
