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.


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
  PHP

  define('DISABLE_WP_CRON', 'true');

  1	define('DISABLE_WP_CRON', 'true');

• ajouter dans le /etc/crontab/ du système
  */1 * * * * root wget -q -O - http://phil.writesthisblog.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

  1	*/1 * * * * root wget -q -O - http://phil.writesthisblog.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

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.