Fastcache permet de mettre devant certaines pages du site (par exemple, la page d’accueil, la page jquery.js, le flux backend/RSS...) un cache rapide qui évitera de solliciter toute la machinerie de SPIP à chaque hit. Il est utile aussi pour un article victime de son buzz !!
Prérequis
A noter :
pour l’activer sur une page, il faut vérifier que cette page doit bien afficher la même chose pour tous les visiteurs (hormis balise
#SESSION), donc pas de <?php echo $_SERVER[REMOTE_HOST] ?> ou d’horloge en php ;-)
il suffit sur le squelette correspondant d’ajouter la balise #FASTCACHE, par exemple juste après #CACHE{3600}
Installation
L’installation n’est pas tout à fait automatique, car il y a un fichier spip.php à mettre à la place du fichier officiel à la racine. Le plugin peut le faire à votre place si les droits correspondent, sinon c’est un processus manuel (ftp). Le spip.php en question est compatible 1.9.2 et SVN, et continue à fonctionner même si le plugin est désactivé.
Si on a cfg, on peut se rendre sur la page
ecrire/?exec=cfg&cfg=fastcache pour régler quelques paramètres.
Pour l’activer dans un squelette, ajouter la balise #FASTCACHE.
Le système est compatible avec la balise #SESSION, les visiteurs disposant d’un cookie de session n’étant jamais envoyés sur le cache rapide. En dehors de ce cas, si un squelette doit afficher quelque chose de spécifique pour chaque visiteur, il n’est pas compatible avec #FASTCACHE.
Fonctionnement
Fast Cache est compatible avec les stats de SPIP, mais son efficacité est beaucoup plus grande lorsque les statistiques des visites sont désactivées.
Chez moi (Fil) ce plugin permet de servir 4 fois plus de pages que le SPIP normal, si les stats sont activées, et 50 fois plus [1] si les stats sont désactivées. Donc des performances comparables à celles d’Expresso, avec un approche complètement différente (pas de défi du merge, ici***
Ce qu’on y risque
On perd un peu en souplesse par rapport au modèle général des squelettes de SPIP : s’il y a du php dans un squelette, qui affiche (par exemple) le numéro IP du visiteur, ce numéro sera stocké dans le cache rapide et servi tel quel au visiteur suivant. Il faut donc s’assurer qu’on n’a pas un schéma de ce genre avant d’ajouter la balise #FASTCACHE.
Si on met la balise dans le squelette article.html, on risque potentiellement d’avoir beaucoup trop de fichiers "fc_*" dans le répertoire tmp/cache/ ; on manque encore de recul sur ce point.
Le plugin n’est pas (pas encore ?) compatible avec la mutualisation : en effet on se base sur un répertoire tmp/ avant même de savoir de quel site mutualisé il s’agit.
Rien d’autre à priori.
Ce qui est bien géré
Dans la mesure du possible le système est compatible avec les fonctionnalités de SPIP :
un visiteur ayant un cookie de session n’est pas routé sur le cache rapide : la personnalisation reste donc possible ;
toute modification substantielle de la base de données (ajout ou modération d’un forum, modification d’un article) est répercutée dans les caches rapides : le site n’est donc pas "gelé" ;
quand on clique sur un bouton de recalcul, tous les caches rapides sont supprimés (réactivité instantanée) ;
en cas de souci, il suffit de désactiver le plugin et de vider le cache, pour retrouver le fonctionnement normal.
d’où celà peut-il provenir ?
autres question :
RSS 2.0