En discutant l’autre jour avec un ami utilisant pas mal la plateforme WordPress, l’idée est venue de parler des performances du moteur. Certains de ses sites étant assez utilisés, la performance n’est pas toujours au rendez-vous. L’idée est donc de propose une configuration un peu plus rapide et moins gourmande pour la machine.

Point de départ

On commence donc par une installation standard Debian Squeeze (dans mon cas), apache2 et la dernière version de WordPress. On va ajouter un article de type LoremIpsum pour remplir la page et regarder ce que ça donne. La machine est une machine virtuelle avec 512 Mo de RAM, rien de très follichon. Je vous la fais courte

ab -c 5 -n 10 'http://xxx/'
...
Total transferred:      131473 bytes
HTML transferred:       128633 bytes
Requests per second:    2.80 [#/sec] (mean)
Time per request:       1786.356 [ms] (mean)
Time per request:       357.271 [ms] (mean, across all concurrent requests)
Transfer rate:          35.94 [Kbytes/sec] received
...

Ouais, donc nativement comme ça, template de base, peu d’images on tourne à 2.8 requêtes par seconde. Temps moyen de réponse 1786 ms. Le programme ab n’est qu’un indicateur qui va nous permettre de mesurer l’amélioration. On peut utiliser d’autres outils de mesures de montée en charge d’un site web comme loadimpact par exemple.

Le plugin W3 Total Cache

Première chose qu’on va faire, c’est de mettre en place ce plugin. C’est assez vite fait, et l’amélioration est flagrande. C’est la version 0.9.2.4 au moment où j’écris ces lignes. J’installe le plugin, et je l’active, que se passe-t-il ? Rien ! Il va falloir en effet le configurer, et c’est là où beaucoup prennent peur !

Donc, dans la page Performance qui est apparue sur la gauche de mon écran, je choisis Preview tout en haut de la page , ce qui me permet de vérifier que le site est bien visible. Il est visible ? Alors je fais Deploy au même endroit. Que me dit ab cette fois ?

Total transferred:      133740 bytes
HTML transferred:       130610 bytes
Requests per second:    39.21 [#/sec] (mean)
Time per request:       127.507 [ms] (mean)
Time per request:       25.501 [ms] (mean, across all concurrent requests)
Transfer rate:          512.15 [Kbytes/sec] received

Déjà, il y a un mieux flagrant, d’ailleurs je dois augmenter le temps de test, car la réponse est trop rapide.

ab -c 50 -n 1000 'http://xxx/'
...
Total transferred:      13374000 bytes
HTML transferred:       13061000 bytes
Requests per second:    61.32 [#/sec] (mean)
Time per request:       815.336 [ms] (mean)
Time per request:       16.307 [ms] (mean, across all concurrent requests)
Transfer rate:          800.93 [Kbytes/sec] received
...

Plus de 60 requêtes par secondes, on a multiplié notre performance par plus de 20 !

Maintenant, sur le serveur, installons le paquet php-apc. Ce dernier va nous permettre de ne mettre en cache les requêtes au niveau php. Après avoir redémarré Apache, on doit voir apparaître l’option APC dans la section Page Cache qui doit être activée. On la choisit.

ab -c 50 -n 1000 'http://xxx/'
...
Total transferred:      13564000 bytes
HTML transferred:       13251000 bytes
Requests per second:    136.58 [#/sec] (mean)
Time per request:       366.081 [ms] (mean)
Time per request:       7.322 [ms] (mean, across all concurrent requests)
Transfer rate:          1809.17 [Kbytes/sec] received
...

Hum, ça commence à être pas mal non ? Plus de 130 requêtes par seconde.

Conclusion

Il y a encore beaucoup d’autres méthodes pour accélérer la réponse de WordPress, mais déjà, en quelques minutes, on lui a donné un bon coup de fouet. Ça fonctionne très bien sur une installation standard. Dans le cas du multisite, il y a des possibilités dont je parlerai dans un prochain article.