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 (comme, par exemple, son numéro IP), il n’est pas compatible avec #FASTCACHE.
Fonctionnement
Fast Cache est compatible avec les stats de SPIP, mais son efficacité est plus grande lorsque les statistiques des visites sont désactivées.
Ce plugin permet de servir 10 à 20 fois plus de pages que le SPIP normal [1] si les stats sont désactivées. Donc des performances comparables à celles d’Expresso, avec une approche complètement différente.
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 ; en utilisant l’extension php xcache (ou, à terme, memcache ou autre), ce problème disparaît.tmp/cache/ ; on manque encore de recul sur ce point.
- Fastcache est compatible avec la mutualisation.
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.
Discussions par date d’activité
16 discussions
C’est une bombe ce plug.
Je l’ai testé sur le site de notre association (en cours de refonte).
http://aneg.aeroclub.free.fr
La majorité des adhérents consulte sous IE6, sur des configs très anciennes, d’où son grand intérêt.
Seulement, lorsqu’il est opérationnel, il bloque l’execution des javascripts (menus déroulant, splickrbox, thickbox etc.) Sous IE6.
Après vidage du cache, la première exécution est ok, les suivantes sont défaillantes.
Spip 1.9.2d
- d’où celà peut-il provenir ?
autres question :
- Concrètement, à quoi sert le paramètre de durée du cache rapide ?
Pour info :
pour désintaller proprement, ne faut’il pas supprimer aussi le fichier/temp/pre_spip.inc, si l’on conserve le spip.php modifié ?
Ps : fastcache est désactivé pour permettre l’accès aux adhérents (validation du projet).
Merci pour votre écoute et votre aide
Plus de soucis avec cette merveille.
Hélas, je n’ai pas pu isoler la cause de disfonctionnement.
Merci encore à l’auteur.
Répondre à ce message
Je viens de le mettre en service pour les pages d’accueil et les pages de rubrique pour notre site. Je pense que cela accelère vraiment ces pages. Merci !
Je vois que la version SPIP SVN utilise déjà un fichier spip.php plus récent (23/1/2008) que celui de Fastcache (23/12/2007). Comment ne pas passer à côté d’une mise à jour SPIP lorsqu’on utilise ce plugin ?
Salut Paolo,
en fait si spip.php semble plus récent, c’est parce que j’ai commité par erreur celui de fastcache — avant de remettre l’ancien. C’est un fichier qui change très peu. Peut-être fastcache passera-t-il un jour dans le core, je ne sais pas. En attendant, ne t’inquiète pas, je suis l’histoire de près.
Répondre à ce message
Très intéressant !!! Malheureusement, je ne trouve pas de lien vers les fichiers à installer. Comment dois-je procéder ?
Comme le plugin est encore en développement il n’y a pas de zip disponible, tu peux donc le trouver ici
Pour le télécharger il faut que tu utilises toirtoise svn pour récupérer les sources sur spip-zine
Répondre à ce message
Après quelques tests, si j’ai bien compris, une page mise en cache avec FASTCACHE ne tiendra plus compte d’un délais plus court qu’on donnerait à un INCLURE dynamique. Ce dernier se comporterait alors comme un INCLURE statique ?
Tu peux régler la durée du cache rapide (par défaut, 180s)
Répondre à ce message
J’ai pas compris, c’est quoi le problème avec le squelettes des articles ?
Sinon, si on fait des
<inclure>, fastcache passe bien aussi n’est ce pas. Du coup, si on met pas le fastcache sur le article.html, c-est grave de le mettre sur les squelettes inclus par ce squelette ?A priori il faut mettre #FASTCACHE sur le premier squelette ; je n’ai pas testé si ça marchait si on l’indique dans les inclusions. Ca marche aussi sur article.html, la seule inconnue c’est ce qui se passe si on a un trop grand nombre de pages dans le cache rapide (il n’y a aucun contrôle de la taille du cache).
Je viens le test et ça ne fonctionne pas si on ajouteavec un INCLURE dynamique.
Répondre à ce message
Histoire de voir je viens d’activer Fastcache sur Contrib. Si le site se traine ou explose on saura pourquoi ;-)
Sinon j’ai mis la balise #FASTCACHE sur :
- sommaire
- backend et backend-forum
- mots
- rubrique
- recherche (par curiosité, histoire de voir si cela permet de resservir plus vite les recherches déjà faites)
- article (malgré l’avertissement ci-dessus, histoire de tester)
@+ NicolasR
bon évidemment j’ai purgé le cache après avoir modifié les squelettes. Je suppose qu’il faut attendre qu’il se reconstitue avant de pouvoir bénéficier des accès plus rapide à celui-ci.
@+ NicolasR
Je ne sais pas à quelle heure tu l’as activé mais de bout de l’internet, spip-contrib n’a jamais aussi bien répondu (enfin pas depuis longtemps).
juste avant le message d’annonce qui a été rédigé dans la foulée (l’heure indiquée me semble être l’heure locale en france).
@+ NicolasR
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires :
|
