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.

wordpress

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 Cache

Les 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 :

a2enmod rewrite

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 :

<?php
phpinfo();
?>

En accédant à cette page via le navigateur, une section XCache devrait apparaître :

phpinfo-xcache

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 :

xcache-122-administration

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 ) :

extension=memcache.so

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 :

phpinfo-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 ;)

 


 

27 réponses pour "WordPress : optimiser son blog avec un système de cache"

  1. Defaite  Surfe sur Internet Explorer Internet Explorer 7.0 avec Windows Windows Vista
    25 juin 2008 @ 10:15
    1

    Super article ! Très complet et tu décris très bien comment procéder.

    Je vais tester tes solutions, j’ai pas (encore) ce genre de problème au vu du nombre de visiteurs que j’ai mais on ne sait jamais ;)

  2. odenis  Surfe sur Mozilla Firefox Mozilla Firefox 3.0 avec Windows Windows XP
    25 juin 2008 @ 11:15
    2

    Super article ! Merci. Me reste plus qu’a avoir des visiteurs :lol:

  3. henri  Surfe sur Mozilla Firefox Mozilla Firefox 3.0 avec Windows Windows XP
    25 juin 2008 @ 14:14
    3

    comme à ton habitude un article très documenté et fouillé, bravo!

  4. PLUGIN WORDPRESS INUTILE DONC INDISPENSABLE : FORTUNE  Surfe sur WordPress WordPress 2.5.1
    30 juin 2008 @ 17:18
    4

    […] citations via JavaScript pour que celles-ci changent à chaque rafraichissement de page même si les pages sont en cache avec WP Super Cache par […]

  5. MogLokeliecdog  Surfe sur Internet Explorer Internet Explorer 6.0 avec Windows Windows 98
    03 août 2008 @ 1:13
    5

    Thanks !

  6. Amaury  Surfe sur Mozilla Firefox Mozilla Firefox 3.0.1 avec Mac OS X Mac OS X 10
    26 août 2008 @ 13:15
    6

    Le code de WordPress n’est pas si dégueulasse que ça ;)

    Article très complet sinon, bien que tu mélange un peu toutes les technos ;)
    Et tu ne parles pas du cache internet de WP qui est également un très compromis pour garder les fonctionnalités des plugins intactes, couplé ou non à Memcached ;)

    Cependant, je précise que ce genre de manipulation n’est utile que pour les Geeks et les personnes à gros traffic, genre presse-citron, et encore…

  7. Plugins et astuces pour sécuriser et optimiser WordPress  Surfe sur WordPress WordPress 2.6.1
    31 août 2008 @ 5:55
    7

    […] WordPress : optimiser son blog avec un système de cache (Papy Geek, 25/06/08) […]

  8. WordPress: Utiliser un système de cache - Emmanuel GEORJON  Surfe sur WordPress WordPress 2.6.3
    15 novembre 2008 @ 9:18
    8

    […] Vous trouverez des détails et les modes d’installation de ces plugins chez PapyGeek. […]

  9. Optimisation serveur et blog Wordpress, les Bases! » JaXX.org  Surfe sur WordPress WordPress 2.6.3
    22 novembre 2008 @ 1:53
    9

    […] Chez PapyGeek : WordPress : optimiser son blog avec un système de cache […]

  10. Chabada » Blog Archive » Plugins et astuces pour sécuriser et optimiser WordPress  Surfe sur WordPress WordPress 2.7
    14 décembre 2008 @ 2:37
    10

    […] WordPress : optimiser son blog avec un système de cache (Papy Geek, 25/06/08) […]

  11. fredo  Surfe sur Mozilla Firefox Mozilla Firefox 3.0.4 avec Windows Windows XP
    15 décembre 2008 @ 16:32
    11

    merci super tuto ( +1 pour MemCached )

  12. binbin  Surfe sur Mozilla Firefox Mozilla Firefox 3.0.5 avec Windows Windows XP
    13 janvier 2009 @ 14:22
    12

    Je me posais une question (peut être idiote) au sujet du cache.

    Je compte lancer mon site/blog en utilisant wordpress 2.7 et je me demandais si les images en « CSS background » était mis en cache d’origine sans l’utilisation supplémentaire d’un plugins ? ( par exemple dans ton header tu as ton avatar simpsons, à chaque ouverture d’une nouvel page j’imagine que l’image n’est pas retéléchargé à chaque fois, mais mis en cache après le premier téléchargement, c’est bien ça ? )

    Merci

  13. Papy  Surfe sur Mozilla Firefox Mozilla Firefox 3.1b2 avec Windows Windows XP
    13 janvier 2009 @ 14:38
    13

    @binbin – En fait ce n’est pas vraiment le même cache dont on parle au dessus.
    Les systèmes de cache tels que WP SuperCache stockent la page html une fois qu’elle a été complètement calculée côté serveur (avec les traitements PHP et autres).

    Pour les images en « CSS background », elles sont traitées comme n’importe quelle image de la page : elles sont envoyées à tous les visiteurs (il n’y a pas de traitement particulier à faire avant) et seront mises en cache dans le navigateur.
    C’est du côté du client que cela se passe.

  14. Olivier  Surfe sur Mozilla Firefox Mozilla Firefox 3.0.5 avec Windows Windows XP
    27 janvier 2009 @ 15:34
    14

    Très bon article !
    Avez-vous trouvé un moyen pour évaluer les (gains en ) performances de WP Super Cache ? Je vois le nb de fichiers en cache mais je n’arrive pas à évaluer si ça fait gagner des ressources

  15. Mealin  Surfe sur Mozilla Firefox Mozilla Firefox 3.0.10 avec Windows Windows 7
    03 mai 2009 @ 20:52
    15

    Article très complet et intéressant, en le couplant avec un ou deux autres j’ai réussi à gagner pas mal en temps d’affichage. Merci encore ;-)

  16. PassiveEco  Surfe sur Mozilla Firefox Mozilla Firefox 3.5b4 avec Windows Windows XP
    14 mai 2009 @ 18:07
    16

    Merci pour ces précision très intéressantes sur les types de cache. Je reste sur WP Super Cache pour l’instant mais ai quand même du mal à voir le niveau de gain qu’il procure sur un blog peu (pas encore assez :cry: ) visité.

  17. fredo85  Surfe sur Mozilla Firefox Mozilla Firefox 3.0.13 avec Windows Windows Vista
    06 août 2009 @ 18:30
    17

    salut , quand tu as plusieurs blogs sur un même serveur ça devient la catastrophe avec memcached du genre affichage d’ élément du blog A sur le blog B . Koreus propose une solution ( http://blog.koreus.com/memcached-backend-plusieurs-wordpress/ ) je n’ ai pas encore testé .

  18. Iron Star  Surfe sur Mozilla Firefox Mozilla Firefox 3.0.11 avec Windows Windows XP
    22 août 2009 @ 12:13
    18

    Excellent article, c’est vrai.

    Par contre, petit bémol concernant WP-SuperCache : la gestion CPU et mémoire provoquant des surcharges aléatoires provoquant des « pétages » de serveur. Alors, pour ceux qui l’utilisent (dont je fais partie), n’hésitez pas à monitorer régulièrement votre serveur pour anticiper les plantages. Pour ma part, mon hébergeur à installé un script qui relance APACHE au cas où le niveau de mémoire utilisée deviendrait trop grand, mais avant et en cas d’augmentation non justifiée, je désactive et ré-active WP-SuperCache sur mes blogs les plus importants. Jusqu’ici, ça fonctionne comme ça, même si ce n’est pas très élégant… en attendant mieux.

    Autre chose concernant les caches : ceux qui utilisent des CSS dynamiques (un pour IE, un pour FF, etc…) ne doivent pas utiliser de caches… on voit pourquoi.

  19. Des Geeks et des lettres  Surfe sur Opera Opera 9.80 avec Windows Windows 7
    21 octobre 2009 @ 22:40
    19

    Merci pour ces conseils avisés qui me sont utiles sur mon site dédié aux geeks et à la littérature. ++ :pirate:

  20. LinKuFF  Surfe sur Mozilla Firefox Mozilla Firefox 3.5.4 avec Windows Windows 7
    01 novembre 2009 @ 16:43
    20

    Par Iron StarExcellent article, c’est vrai.

    Par contre, petit bémol concernant WP-SuperCache : la gestion CPU et mémoire provoquant des surcharges aléatoires provoquant des « pétages » de serveur. Alors, pour ceux qui l’utilisent (dont je fais partie), n’hésitez pas à monitorer régulièrement votre serveur pour anticiper les plantages. Pour ma part, mon hébergeur à installé un script qui relance APACHE au cas où le niveau de mémoire utilisée deviendrait trop grand, mais avant et en cas d’augmentation non justifiée, je désactive et ré-active WP-SuperCache sur mes blogs les plus importants. Jusqu’ici, ça fonctionne comme ça, même si ce n’est pas très élégant… en attendant mieux.

    J’ai exactement ce même soucis sur mon serveur. As-tu trouvé une solution plus « pro » comme l’optimisation apache ou autre sans avoir à rebooter apache tt le temps ? Un serveur devrait être capable de tourner sans ce genre de manip normalement :)

  21. Wordpress : optimiser la vitesse d’affichage | MACCILABO  Surfe sur WordPress WordPress abc
    20 décembre 2009 @ 22:19
    21

    […] en savoir plus sur le sujet, je vous conseille la lecture de l’article WordPress : Optimiser son blog avec un système de cache, d’où sont extraits ces quelques […]

  22. gwenm  Surfe sur Mozilla Firefox Mozilla Firefox 3.5.7 avec Windows Windows Vista
    10 janvier 2010 @ 21:37
    22

    Punezz! Fo bac + 5 pour faire tout ca :ike:

    Bravo pour tes explication :thumbsup:

  23. best nitric oxide  Surfe sur Mozilla Firefox Mozilla Firefox 2.0.0.6 avec Windows Windows XP
    27 avril 2010 @ 11:44
    23

    this is very interesting and true, will share on my blog

  24. Monsieur Buzz  Surfe sur Google Chrome Google Chrome 4.1.249.1064 avec Windows Windows 7
    04 mai 2010 @ 11:21
    24

    Merci pour ce super article.

  25. Daniel Roch  Surfe sur Mozilla Firefox Mozilla Firefox 3.6.12 avec Windows Windows XP
    10 décembre 2010 @ 13:47
    25

    Waouh, il est rare de trouver un article dédié aux systèmes de cache aussi bien détaillé et précis.

    Seul défaut, il ne peut s’appliquer que sur les hébergements dédiés, car la plupart des mutualisés vont bloquer la plupart des conseils donnés ici. Dommage comme on dit…

    Pour les caches plus simples cités au début, je conseille également Super Cache, auquel il faut ajouter DB Cache Reloaded (comme le montre le test que j’avais réalisé il y a quelques mois : quel plugin de cache pour WordPress ?).

  26. MagmaGeek  Surfe sur Mozilla Firefox Mozilla Firefox 3.6.13 avec Windows Windows Vista
    19 février 2011 @ 12:51
    26

    Super article très complet, merci !

  27. fred  Surfe sur Safari Safari 533.21.1 avec Mac OS X Mac OS X 10.6.7
    18 avril 2011 @ 14:45
    27

    J’ai bien XCache d’installé mais je ne trouve pas les fichiers pour l’administration.
    « /usr/share/xcache/admin/ » n’exsite pas et je ne trouve rien non plus avec « locate xcache ».
    Je suis sous Debian Lenny

    PHP 5.3.6-6~dotdeb.0 with Suhosin-Patch (cli) (built: Apr 17 2011 13:37:29)
    Copyright (c) 1997-2011 The PHP Group
    Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
    with XCache v1.3.1, Copyright (c) 2005-2010, by mOo
    with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH

    Peut etre ce sont mes sources qui sont mal configurées ?

    # cat /etc/apt/sources.list
    deb ftp://mir1.ovh.net/debian/ lenny main contrib non-free
    deb-src ftp://mir1.ovh.net/debian/ lenny main contrib non-free

    deb http://security.debian.org/ lenny/updates main contrib non-free
    deb-src http://security.debian.org/ lenny/updates main contrib non-free
    deb ftp://mirror.ovh.net/volatile.debian.org/ lenny/volatile main contrib non-free

    deb http://packages.dotdeb.org oldstable all
    deb-src http://packages.dotdeb.org oldstable all
    deb http://php53.dotdeb.org oldstable all
    deb-src http://php53.dotdeb.org oldstable all

    deb http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free
    deb-src http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free

PapyGeek n'aime personne, sauf PapyGeek. +