15 Mai

Optimiser WordPress avec NGINX et W3 Total Cache – Fin

Suite à l’article précédent, on dispose maintenant, grâce aux mécanismes de cache de W3 Total Cache (W3TC), d’un site WordPress relativement bien optimisé et résistant aux pannes PHP/MySQL. Il ne reste plus maintenant qu’à précharger ce cache afin qu’une version de chaque page y soit déjà présente à chaque nouvelle visite. Ce point est particulièrement important avec les paramètres « Inline CSS minification » et « Inline JS minification » qui assomment le CPU avec, sur ce blog, 6 à 8s pour générer la page d’accueil.

Pré-charger le cache W3TC

W3TC dispose d’une option « Cache Preload » qui répond à ce besoin.

W3TC cache preload
A chacun ses réglages, les miens sont censées précharger une page du site chaque minute… Malheureusement, ce n’est pas si simple.

Un Générateur de Sitemap doit être Installé

Quand W3TC explique qu’un sitemap peut-être utilisé, il faut comprendre que, sans sitemap, seule la page d’accueil sera pré-chargée !! Pour mon blog, j’utilise Google XML Sitemaps qui fait partie des plug-ins de WordPress les plus populaires. Au passage, j’intègre les règles Nginx proposées par ce plug-in à l’intérieur d’un bloc « location » afin d’éviter 4 « rewrites » inefficaces à chaque requêtes clients. Cela permet en plus de paramétrer les headers.

Je recommande fortement de ne pas cacher les sitemaps avec W3TC. Déjà l’intérêt n’est pas évident, et W3TC cache les .xml dans des fichiers .html ce qui pose des problèmes d’affichage.

Désactiver le CRON de WordPress

Armé des sitemaps, W3TC va maintenant utiliser le mécanisme de CRON interne de WordPress pour précharger le cache. A chaque requête client PHP sur le site, WordPress fait en parallèle une requête http sur /wp-cron.php qui exécute les « tâches planifiées » dont celles de W3TC. On en trouve la trace dans les logs :

Ce mécanisme est utile quand l’accès à la crontab du système n’est pas autorisé comme sur un hébergement mutualisé par exemple. Mais il présente deux effets indésirables :

  • Sans visiteur pendant plusieurs heures, le CRON a autant de tâches planifiées à rattraper
  • Sur un site à fort trafic, la quasi totalités des requêtes wp-cron.php sont inutiles et finissent par coûter

Le CRON de WordPress est donc à éviter dès que possible. Pour cela, il suffit de :

  • le désactiver en ajoutant dans le wp-config.php
  • ajouter dans le /etc/crontab/ du système

Bizarrement, j’ai du placer le define vers le début du fichier wp-config.php pour qu’il soit pris en compte. Avec cette configuration, le wp-cron.php sera exécuté chaque minute rajoutant une page supplémentaire au cache. Pour un debug rapide, on peut regarder si le cache se remplit bien dans le répertoire /wp-content/cache/page_enhanced/phil.writesthisblog.com/. Ces réglages sont bien sûr à adapter en fonction du serveur, du trafic et de la nature du site WordPress.

Pour Conclure

Voilà, c’est fini pour les optimisations côté serveur. Si vous en connaissez d’autres je suis preneur, mais à part configurer Nginx pour jouer directement avec le memcache ou le fastcgi_cache, je ne vois pas vraiment.
Question performance, j’ai pu trouver un benchmark très intéressant qui établissait des pointes à 2400 requêtes par secondes sur un VPS, soit l’équivalent d’une centaine de visiteurs par secondes sur un blog comme le mien (~25 contenus sur la page d’accueil). Bien évidement, à ce niveau de trafic, l’idée n’est pas d’optimiser un peu plus Nginx mais de passer à un serveur plus solide.
Question temps d’affichage, je crois que je suis bon. Normalement, les améliorations se font sentir sans même avoir besoin de les mesurer.

test sur tools.pingdom.com

Une pensée sur “Optimiser WordPress avec NGINX et W3 Total Cache – Fin

    • Il y a Zend qui vient avec php5.5. Mais Zend fourni un object cache (en gros le code php est compilé en code machine "opcode" et zend garde une copie de la version compilée). D’après ce que j'ai pu voir, W3TC ne fourni pas de support pour Zend. En même temps, normalement si tu actives bien le cache de zend avec php5-fpm, tu peux désactiver sans perte de performance le opcache de W3TC. Ce que je viens de faire d'ailleurs pour tester. :-)Maintenant, la config que j'ai fournie ne s'occupe que du cache page et minify créé par W3TC. A la limite, si APC ou memcache posent des problèmes avec ton wordpress/W3TC, désactive le cache BDD et le cache objet. Le cache objet parce qu'il est déjà géré par Zend/php5-fpm en amont. Le cache BDD parce qu'après tout, les visiteurs du sites ne voient que le contenu statique html qui ne fait pas appel à la BDD. Donc tu devrais pouvoir vivre sans, la BDD n'étant sollicitée que par les utilisateurs enregistrés.J'espère que je réponds bien à ta question.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.