WordPress est souvent au coeur du débat en ce qui concerne ses performances.
En tant que lecteur, vous avez sûrement rencontré quelques pages affichant des erreurs 500 ou MySQL sur un blog WordPress.
En tant que blogueur, vous étiez enfin parvenu à obtenir un lien depuis Digg ou Presse Citron, et manque de chance, votre blog s’effondre à ce moment là.
Pire encore, vous êtes devenu un hardcore-blogueur et trustez depuis peu les classements Wikio et Google Trends, mais votre site affiche une page blanche une fois sur deux.
Alors que faire ? Vous pouvez toujours pester sur “le-code-dégueulasse-de-WordPress, DotClear-c’est-vachement-plus-propre-et-écolo” ou chercher une solution.
Ca tombe bien, il en existe un certain nombre.
Premièrement, et avant d’aller plus loin, pas la peine d’espérer absorber un trafic “monstre” sur un hébergement mutualisé. Un moment ou à un autre, les problèmes vont arriver et vous ne pourrez que faire durer un peu le plaisir en optimisant votre blog. Mais puisque vous êtes gentils, on va tout de même en parler un peu.
Les systèmes de cache sur disque
Cache fichier simple
Vous ne le savez peut-être pas, mais WordPress intégrait un système de cache sur disque depuis sa version 2.0. Ce cache s’activait en ajoutant dans son fichier wp-config.php la ligne suivante :
define('ENABLE_CACHE', true); // Enable the WordPress Object CacheLes performances de ce cache étant plutôt décevantes, il fut désactivé dans la version 2.1 de WordPress pour finalement être supprimé dans la version 2.5. Pas la peine de courir sur votre fichier wp-config.php donc.
Pour ceux désireux de retrouver cette option de cache sur disque, les petits gars de chez NeoSmart ont développé un plugin réintrégrant cette fonctionnalité.
L’avantage d’un tel système de cache est qu’il est compatible a priori sur tous les environnements : aucune extension particulière n’est nécessaire, ce qui en fait donc un candidat intéressant pour les hébergements mutualisés.
Pour le téléchargement, ça se passe ici. Décompressez ensuite le fichier et transférez le sur votre hébergement dans wp-content.
Ce qui donne directement depuis le serveur pour ceux ayant une connexion SSH :
cd /var/www/votresuperblog/wp-content
wget http://neosmart.net/downloads/software/WordPress/Plugins/object-cache/file-object-cache_1.0.zip
unzip -p file-object-cache_1.0.zip > object-cache.php.filebased
N’oubliez pas de donner les bons droits au fichier (à personnaliser évidemment) :
chown www-data:www-data object-cache.php.filebased
Puis, pour activer le cache, il suffira de faire :
cp -p object-cache.php.filebased object-cache.php
Le super cache : WP Super Cache
C’est le système de cache le plus connu pour les blogs sous WordPress.
Il est une amélioration du plugin WP-Cache 2 qui s’occupait déjà de créer des fichiers de cache des objets du blog.
WP Super Cache va plus loin : il crée pour chaque page appelée un fichier HTML (ou même html.gz) de la page. Vous aurez donc une copie complète de votre blog au format HTML sous wp-content/cache/supercache. Au niveau performances, elles seront excellentes puisque seul apache sera utilisé pour transférer les pages à vos visiteurs, et PHP/MySQL périodiquement pour rafraichir les pages.
Il existe même une fonction permettant de résister à la plupart des Digg Effect : le “Lock Down” qui permet de verrouiller les fichiers de cache et donc de ne pas les régénérer quand un nouveau commentaire est publié.
Pour utiliser WP Super cache, il faudra que votre hébergement supporte la réécriture d’URL via le fichier htaccess présent à la racine du blog. C’est un facteur qui peut être bloquant sur certains hébergements mutualisés.
Pour ceux en hébergement dédié, c’est le module rewrite qui est utilisé, et qui peut s’activer sous Apache 2 facilement avec un :
Vous devrez également utiliser une structure d’URL autre que celle par défaut (Réglages->Permaliens dans l’administration de WordPress).
Pour le reste, je vous laisse suivre la procédure d’installation.
Cache mémoire ou accélérateur PHP
Il existe plusieurs extensions WordPress permettant d’utiliser un système de cache mémoire ou certains accélérateurs PHP.
Ils nécessiteront tous une configuration particulière de PHP et/ou l’installation de binaires supplémentaires sur le système, ce qui en fait une solution réservée aux hébergement dédiés ou privés.
Dans tous les cas, l’installation sera la même : il suffira de copier un fichier object-cache.php dans wp-content.
XCache
XCache est un cache d’opcode, c’est à dire un cache permettant de stocker les fichiers générés par PHP juste avant leur exécution.
XCache est développé par le créateur de lighttpd (lighty), un serveur Web très performant utilisé par exemple par YouTube, Wikipedia et Mininova. Il est souvent utilisé pour distribuer le contenu statique (images, vidéos, CSS...).
Avant d’installer le plugin XCache pour WordPress, il vous faudra installer XCache pour PHP.
Si votre système ne date pas de la guerre (vous n’utilisez plus Firefox 1 n’est-ce pas ?), la commande suivante devrait faire l’affaire :
apt-get install php5-xcache
Il faudra ensuite légèrement modifier la configuration d’XCache dans /etc/php5/conf.d/xcache.ini en modifiant certaines variables comme ci-dessous :
; to disable: xcache.size=0
; to enable : xcache.size=64M etc (any size > 0) and your system mmap allows
xcache.size = 64M
...
; same as aboves but for variable cache
xcache.var_size = 16M
Les valeurs sont données à titre indicatif, elles doivent seulement être non nulles.
N’oubliez pas de rédémarrer apache :
/etc/init.d/apache2 restart
Pour vérifier le bon chargement d’XCache, il suffit de créer un fichier phpinfo.php avec le contenu :
En accédant à cette page via le navigateur, une section XCache devrait apparaître :
Il ne vous restera plus qu’à télécharger le plugin XCache pour WordPress disponible sur cette page.
Ou directement depuis votre serveur :
cd /var/www/votresuperblog/wp-content
wget http://neosmart.net/downloads/software/WordPress/Plugins/object-cache/xcache-object-cache_0.6.zip
unzip -p xcache-object-cache_0.6.zip > object-cache.php.xcache
On donne les bons droits au fichier :
chown www-data:www-data object-cache.php.xcache
Et une petite copie pour activer le cache :
cp -p object-cache.php.xcache object-cache.php
Pour surveiller le travail d’XCache, il faut paramétrer l’accès à la page d’administration. Pour cela, dans /etc/php5/conf.d/xcache.ini, paramétrez les variables “xcache.admin.user” et “xcache.admin.pass“.
Pour la variable xcache.admin.pass, il faut donner le md5 de votre mot de passe, vous pouvez l’obtenir en tapant :
echo -n "montmotdepasse" | md5sum
Modifiez ensuite la configuration d’apache en ajoutant la ligne :
Alias /xcache-admin/ /usr/share/xcache/admin/
(En supposant que les pages d’admin d’XCache se situent dans /usr/share/xcache/admin/. La commande “locate xcache” devrait vous aider à trouver le bon répertoire.)
Visitez la page /xcache-admin/ dans votre navigateur pour observer l’activité d’XCache :
MemCached
MemCached est un système distribué de cache d’objets en mémoire. Vous pouvez donc très bien installer le système de cache mémoire sur une autre machine que celle hébergeant votre site, et même multiplier les machines de cache.
Pour information, Facebook utilise plus de 800 serveurs Memcache. Twitter les utilise massivement aussi.
Pour installer memcached, il faudra donc deux choses : le service en lui-même ainsi que les modules et librairies nécessaires. Ce qui donne :
apt-get install memcached php5-memcache
a2enmod mem_cache
Puis, rajouter à la fin de la configuration de PHP (/etc/php5/apache2/php.ini et/ou /etc/php5/cli/php.ini ) :
Un petit démarrage de memcached et un redémarrage d’Apache et tout devrait fonctionner :
/etc/init.d/memcached start
/etc/init.d/apache2 restart
Pour vérifier tout ça, jetez un coup d’oeil à phpinfo comme au dessus qui devrait afficher une section memcache :
Il faut enfin installer le plugin memcached pour WordPress téléchargeable ici.
Soit en ligne de commande :
cd /var/www/votresuperblog/wp-content
wget http://dev.wp-plugins.org/browser/memcached/branches/1.0/memcached-client.php?format=raw -O memcached-client.php
wget http://dev.wp-plugins.org/browser/memcached/trunk/object-cache.php?format=raw -O object-cache.php.ryan
On donne les bons droits aux fichiers :
chown www-data:www-data memcached-client.php object-cache.php.ryan
Et une petite copie pour activer le cache :
cp -p object-cache.php.ryan object-cache.php
Et voilà!
MemCached + BatCache
BatCache est un nouveau venu dans le monde des plugins de cache WordPress. Son nom était “supercache” pendant le développement mais comme “Super” était déjà pris, il a fallu trouver autre chose à la sortie du plugin. Je vous laisse imaginer d’où vient le “Bat”...
Le plugin utilise MemCached en backend pour sauvegarder les pages qui sont accédées plus de X fois en Y secondes et les stocke pendant Z secondes. X, Y et Z sont bien sûr paramétrables.
Vous ne pourrez pas utiliser WP Super Cache et BatCache en même temps, à vous donc de choisir entre un cache mémoire et un cache sur disque comme WP Super Cache.
Le créateur du plugin BatCache prétend que son activation réduit de 40 fois le temps de génération des pages de WordPress.
L’installation est détaillée sur cette page, le plugin étant tout jeune, il évoluera certainement dans les mois qui viennent. A suivre donc.
APC
APC est un cache d’opcode au même titre qu’XCache.
L’installation est très proche de celle d’XCache, soit à peu de choses près :
apt-get install php-apc
echo '
extension=apc.so' >> /etc/php5/apache2/php.ini
/etc/init.d/apache2 restart
Le plugin WordPress APC doit lui être copié dans wp-content sous le nom object-cache.php.
eAccelerator
C’est exactement la même chose avec eAccelerator qui est encore un autre cache d’opcode.
Pour l’installation, je vous laisse chercher sur Google pour quelques documentations. C’est relativement simple et rapide.
Le plugin s’installe ensuite comme les autres :
cd /var/www/votresuperblog/wp-content
wget http://neosmart.net/downloads/software/WordPress/Plugins/object-cache/eaccelerator-object-cache_0.6.zip
unzip -p http://neosmart.net/downloads/software/WordPress/Plugins/object-cache/eaccelerator-object-cache_0.6.zip > object-cache.php.eaccelerator
chown www-data:www-data object-cache.php.eaccelerator
cp -p object-cache.php.eaccelerator object-cache.php
Quelle solution choisir ?
En termes de performances, les caches d’opcode se valent. Certains donnent tout de même à XCache une légère longueur d’avance.
Si vous avez déjà un système de cache tel qu’XCache, Memcache, APC ou eAccelerator installé sur votre hébergement, le plus simple est certainement d’utiliser le plugin WordPress correspondant.
Quant à WP Super Cache, il permettra d’éviter la plupart des traitements coûteux, allégeant largement le serveur. La charge répercutée sur les disques (I/O) sera souvent insignifiante vu les volumes échangés. Attention tout de même sur les hébergements mutualisés : vous ne pourrez pas monopoliser les ressources disques du serveur sans vous attirer des problèmes.
WP Super Cache est donc de loin la solution de cache la plus efficace pour un blog WordPress.
Seuls les problèmes d’installation ou les inconvénients de son activation peuvent être bloquants. On peut citer l’incompatibilité avec les plugins générant du contenu dynamique sur une page (par exemple en fonction du referer comme avec landing sites), ou les problèmes avec certains compteurs ou plugins de statistiques.
Je conseillerai personnellement l’utilisation combinée de WP Super Cache + XCache, les deux solutions étant compatibles. WP Super Cache pourra être activé en permanence ou au besoin.
N’hésitez pas à apporter vos retours quant à la solution qui pour vous paraît la plus efficace.
Allez plus loin ?
L’utilisation d’un plugin de cache n’est qu’un moyen parmi d’autres d’optimiser son blog WordPress. Si vous avez entièrement la main sur votre hébergement, optimiser Apache/PHP et MySQL est tout aussi important (et laborieux). Voici quelques pistes souvent évoquées dans ce cadre.
MySQL
Parfois controversée, le cache sur les requêtes SQL peut aider à réduire la charge sur votre base de données. Dans /etc/mysql/my.cnf :
#
# * Query Cache Configuration
#
query_cache_type = 1
Pour alléger MySQL, la meilleure solution reste de réduire le nombre de plugins utilisés et surtout d’éviter ceux très gourmands pour la base : compteurs de visites, WP-Stats et autres plugins générant une ou plusieurs requêtes par visiteur. Il est préférable d’utiliser des équivalents externes en JavaScript : Google Analytics, WordPress.com Stats, etc. Autant alourdir les bases de Google ou de WordPress.com plutôt que la votre.
Apache
La configuration d’Apache est plutôt compliquée et dépend fortement de votre matériel.
Extrait d’un fichier /etc/apache2/apache2.conf :
#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 30
#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On
#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 100
#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 8
##
## Server-Pool Size Regulation (MPM specific)
##
# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 8
MaxSpareServers 50
MaxClients 250
MaxRequestsPerChild 500
</IfModule>
# worker MPM
# StartServers: initial number of server processes to start
# MaxClients: maximum number of simultaneous client connections
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule mpm_worker_module>
StartServers 15
MaxClients 250
MinSpareThreads 10
MaxSpareThreads 100
ThreadsPerChild 100
MaxRequestsPerChild 1000
</IfModule>A vous de tester et de rechercher la meilleure configuration pour votre machine. Les forums d’OVH ou de Dedibox ne manquent pas de discussions sur le sujet.
Si votre site est encore peu utilisé, vous pouvez faire quelques modifications puis les tester en utilisant Apache Bench :
apt-get install apache2-utils
ab -n 1000 -c 10 http://www.monserveur.com/mapagedetest.php
La variable “Requests per second” vous indiquera le nombre de requêtes auxquelles votre serveur pourra répondre chaque seconde (pour la page testée).
PHP
Pour PHP, pensez à désactiver certaines fonctionnalités parfois pénalisantes en terme de performances (et surtout très mauvaises pour la sécurité) :
register_globals = Off
register_long_arrays = Off
register_argc_argv = Off
magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off
Vous pouvez également modifier les limitations en termes de ressources :
;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;
max_execution_time = 60 ; Maximum execution time of each script, in seconds
max_input_time = 30 ; Maximum amount of time each script may spend parsing request data
;max_input_nesting_level = 64 ; Maximum input variable nesting level
memory_limit = 128M ; Maximum amount of memory a script may consume (128MB)
...
; Maximum allowed size for uploaded files.
upload_max_filesize = 6M
Voilà quelques pistes qui j’espère vous aiderons à optimiser votre blog et donc à économiser quelques euros pour votre hébergement. Maintenant la page blanche ne devrait plus venir de votre serveur mais seulement de vous, alors au boulot 
lectures.
^^
Grégoire il est manifiiik !!!
