Installation
Le plugin s’installe classiquement. Il est disponible par git, à l’adresse https://git.spip.net/spip-contrib-extensions/cache_cool.git, ou en zip à télécharger.
Il n’entraine aucune modification de la base de données.
En revanche, le plugin nécessite au minimum la version SPIP 2.0.11, ou, mieux, une version 2.1.x.
Le plugin nécessite également le plugin Job Queue pour la mise en file d’attente du calcul des page en cache.
Comment ça marche
Le plugin s’insère dans le processus de calcul des pages a mettre à jour au moyen de la fonction public_produire_page
.
Si c’est un calcul normal pour une mise en cache, il regarde alors si une version du squelette est déjà disponible et peux être envoyée à l’internaute. Dans ce cas, et si le visiteur n’est pas connecté, il lui envoie la vieille version du cache, et ajoute à la queue un calcul du squelette pour mettre à jour le cache. [1]
Est-ce que ça marche ?
Pour vérifier si le plugin marche, vous pouvez surveiller la queue des jobs en attentes sur ecrire/?exec=job_queue
. Vous devez voir passer des calcul de squelette comme par exemple Calcul du cache inclure/rubriques [inclure_page]
Est-ce-que ça marche vraiment ?
Pour que le plugin soit efficace, il faut que votre site reçoive un traffic suffisament important pour que les caches en attente soient calculés rapidement.
Sur un site à faible traffic, le visiteur verra toujours une vieille page qui sera mise à jour uniquement après son passage. La version à jour ne profitera à personne.
Du point de vue du visiteur, le temps de réaction du site est sensiblement accéléré. Mais il faut que cela ne se paie pas par une information constamment périmée !
Gains attendus
Dans toutes les configurations, le plugin permet un gain sensible et visible sur le temps de service des pages par le serveur. Car l’assemblage d’une page est beaucoup plus rarement ralentie par le calcul d’un morceau de squelette.
Discussions par date d’activité
23 discussions
Bonjour.
Je n’ai rien du style « Calcul du cache inclure/rubriques [inclure_page] » à apparaître dans la queue. J’utilise la version 2.1.1 patché de SPIP. De plus, je ne vois pas d’accélération notable du chargement des pages. Ceci peut expliqué cela.
Bref, une idée de pourquoi ça ne fonctionnerai pas chez moi ?
Merci.
Deux remarques : si tu utilises une version 2.1.1 de SPIP, il ne faut pas la patcher. J’ai corrigé la documentation sur ce point.
Enfin, si tu testes en naviguant toi même dans les pages du site, alors Cache-cool ne te servira jamais des cache froids car tu es connecté à SPIP. Pour éviter de servir des pages qui pourraient contenir des informations liées à un autre visiteur, les caches froids ne sont servis que pour les visiteurs anonymes. Teste en visitant le site avec un autre navigateur, dans une session anonyme.
Tu peux aussi verifier que
tmp/queue.log
contient bien des références au jobpublic_produire_page
.OK.
Quand je parle de version patchée, je parle du patch qui permet de passer de la version 2.1.1 de SPIP à la version 2.1.2 et d’éviter de ne plus afficher tous ses articles dans la partie publique.
J’ai vérifié le contenu de queue.log et je vois effectivement apparaître quelques « public_produire_page ».
Peut-être la lenteur de mes sites SPIP est t-elle due à mon hébergeur alors ???
Voiloù.
Il semble en effet que la lenteur soit liée à la plateforme d’hébergement. Peux tu vérifier que tu n’as pas activé la « Compression du flux HTTP » dans le panneau de configuration des fonctions avancées ?
Une fois la compression du flux http désactivé, ça s’arrange effectivement. Mes pages sont bien plus rapides à chargées quand je navigue en anonyme. Après, ce n’est pas la panacée non plus.
Merci.
Le fait que la compression du flux http fasse ramer le site, et que par défaut apache ne soit pas configuré pour compresser le flux automatiquement traduisent un sous-dimensionnement CPU de la plateforme d’hébergement. Il ne sera pas possible de faire quoi que ce soit au niveau de SPIP pour améliorer cela.
Par contre, je peux conseiller alternativement lautre.net qui est un hébergeur associatif comparable à l’APINC, et dont la plateforme technique semble mieux dimensionnée : lors des derniers tests réalisés pour la release de SPIP 2.1, le site de test y fonctionnait de façon bien plus rapide.
je confirme que l’autre.net ne pose pas de soucis pour du SPIP.
En plus il y a une accés SSH... et ca c’est cool. Vous pouvez tester pendant un mois.
Répondre à ce message
Je viens de mettre Cache Cool sur notre site (que j’ai fait passer à 2.1), et l’accéleration est visible à l’oeil nu. Merci !
Question : Sur quelques pages j’ai aussi Fastcache. Peut-être ce n’est pas la peine de garder les deux ?
Il n’y a pas vraiment de contre-indication à utiliser fastcache & cache-cool, si ce n’est le risque que la page en cache de fastcache soit statistiquement moins fraiche.
Répondre à ce message
Bonjour,
Lorsque vous dites : "
« Le plugin s’insère dans le processus de calcul des pages a mettre à jour au moyen de la fonction public_produire_page »
Il faut mettre soi-même à jour ce processus ou c’est automatique ? S’il faut le faire soi-même, comment ?
Merci
Ainsi qu’indiqué dans le paragraphe sur l’installation, le version 2.0.10 de SPIP n’est pas suffisante pour faire marcher le plugin.
Il faut utiliser le zip de la prochaine 2.0.11 : http://files.spip.org/spip/dev/SPIP-branche-2.0.zip pour mettre à jour SPIP et faire ensuite marcher le plugin sans modification.
Répondre à ce message
J’ai mis un petit patch sur le mien pour que les visiteurs connectés puissent en bénéficier sur les caches qui ne contiennent pas d’infos de session.
Je ne sais pas vraiment s’il y a des failles dans ma façon de faire.
est-ce que tu pourrais poster le patch, cela m’intéresse, merci
Répondre à ce message
Si j’ai bien compris le plugin marche uniquement si le visiteur n’est pas connecté. Est-il possible dce l’acctiver également pour les visiteurs connectés ?
Répondre à ce message
« Warning : Deprecated : Call-time pass-by-reference has been deprecated in /home/racerdaily/httpdocs/plugins/cache_cool/cache_cool_options.php »
il s’agit de la ligne :
gunzip_page(&$page) ; // decomprimer la page si besoin
peut-on éviter cela ?
Répondre à ce message
n’y a-t-il pas possibilité de passer par le cache cool pour un visiteur authentifié quand il s’agit d’un cache non-sessionné ? Du genre utiliser le flag de session... voila, car si on a beaucoup de pages qui ne contiennent pas d’éléments personnalisés, c’est dommage de ne pas utiliser le plugin pour les visiteurs authentifiés tant qu’on le peut.
C’est possible en théorie, à vérifier et confirmer, car on entre là dans un domaine sensible.
Répondre à ce message
Vraiment un très beau travail, j’ai installé ce pugin sur plusieurs sites et pour la première fois pour ce type de plugin, pas de plantage et une véritable efficacité :)
Doc Mac
Répondre à ce message
C’est sans commune mesure, je réalise un site hébergé chez Amen et le problème de lenteur était récurent.
Pour info 7s avant pour afficher l’index contre 1s actuellement
Bravo et merci pour ce plugin
etienne
Répondre à ce message
Salut,
Sur un site encore en beta, donc avec très peu de personnes dessus, la procédure de test est vide.
Je suppose que c’est normal ?
Ya t’il un autre moyen pour tester le bon fonctionnement ?
Merki
J’ai rien dit ...
Ca semble marcher
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 : |