Dans le fil rouge WordCamp Paris 2012, il est venu le temps de parler de l’optimisation des performances de WordPress. Comme nous avions déjà abordé dans nos colonnes comment optimiser les performances des WordPress, nous nous attacherons ici à l’optimisation des performances de WordPress en optimisant celle de la base de données.
Je pense que cela est connu de tout le monde, WordPress est écrit en Php et la base de donnée utilisée est MySQL. MySQL est la clé de voûte de l’édifice, toutes les informations y étant stockées, même une partie des informations de paramétrage de WordPress. Comme toutes les autres plateformes au contenu dynamique, WordPress exécutera une – en faite des – requête(s) sur le serveur MySQL pour afficher la page demandée.
On l’aura tous constaté, sorti de la boite, WordPress est terriblement rapide. Mais avec le temps, ses performances ont tendance à décroître, demandant un temps plus important pour l’affichage d’une page. Cela s’explique par les nombreuses insertions , mises à jour et suppressions des informations dans la base.
Alors si vous voulez retrouver votre WordPress comme au premier jour, il va falloir sortir les gants et commencer le ménage.
Attention !
Oui, attention ! SAUVEGARDEZ VOTRE BASE DE DONNÉE AVANT TOUTE MODIFICATION. Le message ne peut pas être plus clair. Toucher à sa base de données comporte un vrai risque si on ne sait pas ce que l’on fait. Alors avant toute manipulation de cette dernière, une sauvegarde s’impose.
C’est dit.
Connaître le nombre de requêtes exécutées
Optimiser la base de données passe par connaître le nombre de requêtes que votre WordPress doit exécuter pour afficher un type de page car toutes les requêtes MySQL ne se valent pas en terme d’optimisation.
Afficher le nombre de requêtes exécutées par WordPress
Afficher le nombre de requêtes exécutées par WordPress est plutôt simple. Voici comment savoir le nombre de requêtes et le temps que cela demande à MySQL pour les exécuter.
<?phpechoget_num_queries(); ?> requetes en <?php timer_stop(1,3); ?> secondes
Identifier les requêtes
On vous le disait, connaître le nombre de requêtes n’est pas suffisant à proprement parler car toutes les requêtes ne se valent pas. Alors comment faire pour optimiser sa base de données sous WordPress si on ne jette pas un œil sur les requêtes elles-mêmes ? Dans le monde merveilleux de WordPress, pour chaque demande, son plugin. Nous ne ferons pas exception à la norme en vous disant d’utiliser Debug Queries pour identifier vos requêtes gourmandes en temps et en ressources – l’un étant le corollaire de l’autre. Une fois le plugin installé et activé, tout se passe sur le front office de votre site, dans le pied de page.
Voici le types d’informations que Debug Queries remonte.
Utiliser Debug Queries peut-être un moyen très simple d’accélérer votre blog WordPress. Comment cela est-il possible alors que ce plugin se contente d’afficher des requêtes et des temps d’exécution ? C’est simple, Debug Queries vous permet de voir tout de suite le plugin qui pourrait être la cause de tout le ralentissement du site. Si cela était le cas, il vous suffirait de troquer ce plugin contre un autre.
Maintenant que nous connaissons les requêtes talon d’Achille de notre blog WordPress, passons à l’optimisation.
Optimiser les tables de la base de données WordPress
Comme l’indique la documentation MySQL, la première chose à faire est de supprimer l’effet d’Overhead. On peut voir cela soit par son interface PhpMyAdmin, ou si on ne se sent pas à l’aise, utiliser un plugin WordPress pour cela.
Les Plugin WordPress…
Deux plugins s’offrent à nous pour effectuer cette tâche :
… Ou PhpMyAdmin
Utiliser PhpMyAdmin reste tout de même quelque chose de suffisamment simple pour que nous n’éprouvions pas le besoin de surcharger notre site avec de nouveaux plugins.
En trois clics, c’est plié :
- Connectez-vous à votre PhpMyadmin
- Sélectionnez l’option Check tables having overhead.
- Cliquez sur Optimize Table.
Éditer le fichier wp-config.php
Il existe quelques variables à passer à WordPress au travers de votre fichier wp-config.php qui auront pour effet de vous aider à maintenir et optimiser la base de données.
Vider votre poubelle
L’introduction dans la version 2.9 de la poubelle est un pas en avant. Cela permet de ne pas détruire irrémédiablement un document. Il nous est possible d’aller chercher dans la poubelle un article que nous aurions malencontreusement jeté. Par défaut, WordPress videra votre corbeille tous les 30 jours. On peut raccourcir ce temps à deux jours par exemple.
define( ‘EMPTY_TRASH_DAYS’, 10 ); Réparer automatiquement la base
WordPress peut lancer pour vous une tâche périodique de réparation de la base MySQL.
define( ‘WP_ALLOW_REPAIR’, TRUE ); Cette action peut aussi se faire sur demande, en vous rendant sur l’url http://www.monsite.com/wp-admin/maint/repair.php/
Ne plus enregistrer les révisions de billet
Les révisions de billet peuvent-être parfaitement utiles comme inutiles, tout dépend des besoins. Mais ce qui est certain, c’est que les révisions de billet prennent de la place, et même parfois beaucoup de place alors que cela n’est pas forcément nécessaire. WordPress vous propose de ne plus activer cette fonctionnalité.
define( ‘WP_POST_REVISION’, FALSE ); Pour tout vous dire, nous ne l’avions pas désactivé et bien mal nous en a prit. La semaine dernière, suite à une erreur, trois heures de travail se sont vu évaporées au moment de la sauvegarde. Grâce à la révision des billets, nous avons pu retrouver l’ancienne version en moins de 15 secondes.
Supprimer les tables inutiles
Qui ici ne teste pas souvent de nouveaux plugins sur son WordPress ? Certainement pas nous. Mais voila, tester un plugin, cela sous entend l’installer et le désinstaller proprement. Hélas, trop de plugins laissent encore beaucoup de traces derrière eux.
La suppression d’une table est à prendre très au sérieux. Supprimer une table essentielle à WordPress et vous comprendrez vite pourquoi : ) Il est impossible de vous dire quelle table toucher, laquelle ne pas toucher. Mais ce qui est possible, c’est de vous donner la liste des tables présentes nativement sous WordPress, et donc essentielles.
Supprimer les entrées inutiles dans la table wp_options
Si votre plugin possède une page de configuration, il y a tout à parier qu’il stocke ses informations dans la table wp_options. Donc, dans notre optique de plugin testé puis supprimé, qu’advient-il ? Toutes les données sont laissées telles quelles. Si vous vous amusez souvent à ajouter / supprimer des plugins, alors attention car le nombre de lignes dans cette table risque de vous laisser pantois.
Mais voila, aller lire cette table pour l’éditer à la main, c’est une vraie corvée, sans parler du risque de supprimer la mauvaise entrée. Je ne vais pas me répéter, mon merveilleux de wordpress toussa, un plugin existe pour ce besoin; il s’agit de Clean Option.
Mise en cache des requêtes
Utiliser un cache pour les requêtes peut être un bon compromis pour minimiser le temps de traitement sur votre site. Je dis bien “peut être” car la mise en cache de la base de données implique que cette mise en cache soit plus rapide d’accès que l’accès direct à cette base; et sur les serveurs mutualisés notamment, cela n’est pas toujours le cas. Alors vérifiez avec et sans avant de vous décider.
W3 Total Cache a notre préférence pour cela car, en plus de mettre en cache les requêtes SQL, il sait faire pleins de choses ; )
Conclusion
Vous comprenez maintenant mieux comment WordPress travaille avec MySQL et comment rechercher le goulet d’étranglement dans la génération dynamique de votre site WordPress. Il ne vous reste plus qu’à mettre les mains dedans pour profiter de tous ces conseils.
bonjour
en plus du réglage du wp-config sur le nombre de révisions à conserver (par exemple 3)
/* limit number of post revisions */
define(‘WP_POST_REVISIONS’, 3);
il est aussi utile de temps à autres de supprimer les révisions des articles stokées dan la BD
Cette requête SQL va supprimer toutes les sauvegardes antérieures des articles dans la base de données :
DELETE FROM wp_posts WHERE post_type = ‘revision’;
un bon regime minceur pour la table !
Y a pas mieux que l’optimisation directe dans PhpMyAdmin. Attention aux extensions qui ne sont plus mises à jour.
WP_POST_REVISIONS avec un S 😉
Bonjour et merci pour cet article très complet,
– concernant
define( ‘WP_POST_REVISION’, FALSE );
je préfère mettre une valeur de 1 ou 2 qui semble un bon compromis entre la valeur par défaut (-1 ou true) et false.
Article encore une fois intéressant, complet et à la portée des débutants, merci !
PS : quel est le plugin qui permet de s’abonner aux commentaires ?
Si je ne m’abuse Subscribe to Comments Reloaded.
Librement
Et comme plugin de newsletter ? (je n’arrive pas à m’y inscrire)
De bien bonnes infos !
Attention par contre à WP_ALLOW_REPAIR qui ne lance AUCUNE tâhce périodique.
Il semble que tu dises “mettre le define àvrai pour tache périodique ou action manuelle sur http://www.monsite.com/wp-admin/maint/repair.php” cequi est faux.
La page ne peut être visitée QUE si le define est à vrai, et ce define est à supprimer une fois la répération terminée !
Voici le codex :
“Automatic Database Optimizing
Added with Version 2.9, there is automatic database optimization support, which you can enable by adding the following define to your wp-config.php file only when the feature is required
define(‘WP_ALLOW_REPAIR’, true);
The script can be found at {$your_site}/wp-admin/maint/repair.php
Please Note: That this define enables the functionality, The user does not need to be logged in to access this functionality when this define is set. This is because its main intent is to repair a corrupted database, Users can often not login when the database is corrupt. ”
Source – http://codex.wordpress.org/Editing_wp-config.php
Sinon il y a bien plus de 2 plugins qui optimisent la base de données 😉
Nota ajouté dans le billet. Que proposes-tu pour le lancer d’une tâche périodique ?
Pour ce qui est des plugins, j’imagine oui. Mais le but été justement de montrer qu’on pouvait s’en passer 😉
Si tu en connais des vraiment top, fais tourné !