Cache Cool - commentaires

Cache Cool

Bon
en ouvrant le code je vois des constantes vérifiées _DIR_PLUGIN_MEMOIZATION
j'ai donc activé les 2 et ça fonctionne très bien, quelques millisecondes de gagné

ceci dit j'ai aussi poussé la limite à 4.2 et ça fonctionne
dans les 2 cas c'est en php 7.4
pas testé en 8

Merci !
Natacha

Cache Cool

Bonjour
même question
Est-il utile ou contre-productif d'utiliser ce plugin en combinaison avec le plugin memoization ?

une version 4.2 est elle prévue

Merci pour votre plugin
Natacha

Cache Cool

Bonjour,

Merci pour ce plugin. J'ai deux questions :

Est-il utile ou contre-productif d'utiliser ce plugin en combinaison avec le plugin memoization ?

Quelle est la durée du cache de cache-cool et comment la modifier ?

Merci pour votre aide

Cache Cool

Bonjour,

tout d'abord merci pour votre travail, c'est un plaisir de voir que le plugin est régulièrement amélioré. Merci de l'avoir mis à disposition de tous.

excusez-moi pour cette question naïve, mais y-a-t-il quelque chose à inclure dans le code de mon site pour que le plugin fonctionne ?

Je ne vois jamais passer de ligne de cache-cool sur ma page ecrire/ ?exec=job_queue, alors que normalement j'ai des dizaines de visiteurs en ligne d'après google analytics...

Voici ce que je vois dans ma liste :
svp_actualiser_depots
visites
invalideur
popularites
maintenance
optimiser_revisions
optimiser
queue-watch
mise à jour

Je suis sous spip 3.1 avec php7, écran de sécurité, couteau suisse.

Cache Cool

J'ai mis Spip à jour "n 3.0.21, la version php en 5.5, vidé le cache.
Mais j'ai toujours une erreur avec le plugin Cache Cool, même losque je le désactive :
Erreur SQL HY000 / 11
database disk image is malformed
SELECT id_job FROM drama_jobs WHERE fonction='optimiser_revisions'

Lorsque j'essaye de purger la file, j'ai 2 erreurs, dont une ici :
../prive/squelettes/contenu/job_queue.html ligne 5.
Est-ce qu'il y a une modif à faire dans ce fichier ?

Cache Cool

En attendant que ces problemes soient resolus vous pouvez essayer d'utiliser le mode alternatif :

register_shutdown_function() ;

Cela permet de ne pas passer par le job_queue. En gros cette fonctionalite permet d'executer le code PHP cote serveur apres avoir transmis la requete HTTP au visiteur. Moi j'ai switche sur ce mode depuis plusieurs annees maintenant. Je ne sais pas ce que Cedric pense de favoriser cette methode, en tous cas elle est prevue dans le plugin.

J'ai un patche complique pour faire cohabiter le cache cool avec un plugin perso, mais je pense que la methode generale pour changer de mode est de placer cette ligne au debut de cache_cool_options.php :

define('_CACHE_COOL_MODE','NO_QUEUE') ;

La valeur 'NO_QUEUE' est purement arbitraire, en gros on peut mettre ce que l'on souhaite du moment que c'est different de 'QUEUE'.

Cache Cool

Merci Billou, je vais tenter de réinstaller un site miroir en local.
Mais j'aurais bien aimé avoir l'avis de Cédric, il y a peut-être une procédure très simple et non risquée, j'ai peut-être fait une erreur quelque part…
Et surtout, ça me rassurerait quant à l'utilisation du plugin Cache Cool, que j'utilise déjà dans d'autres sites, et peut-être dans les prochains, en fonction de la résolution ou non de mon problème.

Cache Cool

Je ne pense pas que ça soit très grave si cette table n'est pas dans la sauvegarde.

Cache Cool

Bonjour

Même problème, impossible de faire une sauvegarde de la base sans décocher la table spip_jobs :
spip_jobs (31929 enregistrements) !!
J'ai bien essayé avec le bouton à l'adresse ecrire/ ?exec=job_queue
Mais ça plante :
Erreur SQL HY000 / 11
database disk image is malformed
SELECT jobs.date, jobs.id_job, jobs.status, jobs.priorite, jobs.descriptif, jobs.args, jobs.fonction FROM drama_jobs AS 'jobs' ORDER BY jobs.date

Je ne sais plus comment faire pour me sortir de là !!!

Infos :
SPIP 3.0.10
Cache Cool 0.4.1
Base en sqlite

Cache Cool

il y a t'y des raisons de penser que le plugin ne serait pas compatible 3.1 ? si non, comment peut-on procéder à des tests pour savoir à quel moment le cache est effectivement recalculé ?

Cache Cool

Salut,

Est-ce que le plugin est encore utile en SPIP 3.1 ?

Cache Cool

Niquel, merci pour le patch et pour ce plugin Cédric !

Cache Cool

Le bug est corrigé par http://zone.spip.org/trac/spip-zone/changeset/70149 (version 0.3.2 du plugin)

Cache Cool

En effet, un Connection : close est utilisé pour finir le hit et pouvoir calculer les caches ensuite (dans le même hit) sans que le navigateur ne continue à indiquer un chargement de page. Cela évite l'insertion en base de donnée des jobs de calcul, et réduit donc la consommation de ressource.

Je n'avais pas pensé à l'impact sur le KeepAlive et du coup je n'ai pas essayé d'optimiser cela. Je vais regarder pour ne fermer la connexion que si on utilise le mode « calcul en mémoire » Cache Cool (introduit par http://zone.spip.org/trac/spip-zone/changeset/67804/_plugins_/cache_cool et qui n'est pas le mode par défaut pour le moment), et si il y a effectivement des cache à calculer en asynchrone.

Lorsqu'on utilisera le mode « en mémoire » il restera donc des cas où l'on ferme la connexion mais cela évitera des insertions SQL (qui peuvent être lentes et bloquantes en SQLite) ainsi que de lancer d'autres process apache en parallèle. Je pense que c'est un mal pour un bien, mais je vais regarder cela de plus près.

Cache Cool

Personne n'a observé ce problème ?

Cache Cool

Bonjour,

déjà merci pour ce plugin sympathique qui permet d'optimiser intelligemment la gestion du cache.

Je rencontre le problème suivant avec la dernière révision r67806 : les connections HTTP sont systématiquement fermées par le serveur du fait de l'ajout d'en entête « Connection : close ». Du coup plus de keep-alive pour le client...

Normal ?

Aucun soucis avec la r67805.

Cache Cool

J'ai effectivement de nombreuses paginations, croisées qui plus est. L'écran de sécurité étant activé, je pensais être tranquille avec les paginations. Du coté de suhosin je n'en sais rien, je vais poser la question à l'hébergeur.

Merci de ta réponse.

Cache Cool

La compression du flux http il faut éviter, on l'a supprimée de SPIP 3 car c'est contreproductif : soit l'hebergeur l'a deja activé sur apache et ça consomme du cpu pour rien, soit ce n'est pas activé et il y a une raison (et en général, dans ce cas le faire en PHP n'arrange rien).

Le repertoire tmp/contexte c'est un problème. Tu dois avoir suhosin qui bloque les longues URLs et du coup SPIP stocke les contextes sur le disque pour ne pas les faire passer en URL. Il suffit que tu aies des paginations en grand nombre et des boucles infinies d'URL parcourues par les bots pour que ceux-ci produisent un nombre infini de contextes. Il faut tout vider (tmp/contexte et le cache de SPIP) pour repartir de zéro, mais c'est une base pas saine.

Cache Cool

Salut,

J'ai activé job queue et cache cool, le couteau suisse limite le cache à 20Mo comme il peut. Je compresse le flux http. Le site n'est pas un foudre de guerre mais bon. Toutefois j'ai des retours de l'hébergeur qui m'indique un nombre très important de fichiers dans Tmp/contexte. Plus de 2 000 000 de fichiers. Est-ce lié ?

Merci de vos réponses.

Cache Cool

Bonjour.

J'utilise les dernières versions de cache_cool (0.2.4) et job_queue (0.6.5) sur plusieurs sites spip 2.1.12.

Oilà. je suis à la page donc.

Je trouvais mes sites très lents, alors que mais autres appli' s'en portait pas plus mal chez le même hébergeur.

Démarche expérimentale oblige, j'ai testé des paramètres un par un.

En désactivant cache_cool, c'est toujours aussi lent.

En désactivant job_queue, dépendance oblige, cache cool se désactive aussi, mes sites on reprit immédiatement du poil de la bête. C'est flagrant.

Donc, je trouve ça étrange. Je suis prêt à faire d'autres tests si ça intéresse quelqu'un.

À plus.

Ludo

Cache Cool

J'ai le plugin en 0.6.5, spip en 2.1.10 et pourtant la table spip_jobs pèse 58Mo…

Quand je vais à la page d'admin de votre lien, ça me dit ça : « 17632 travaux en attente / Prochain travail dans 0 s »
Il prévoit même des tâches pour Décembre 2012 et 2013 ! Il est prévoyant =D

Est-ce normal ?!

Cache Cool

oui tout à fait, n'hésites pas.

Cache Cool

Le probleme de file de travaux qui ne se vide pas est du dans la plupart des cas a une version SPIP pas a jour, et une version de PHP trop ancienne. La version 0.6.4 du plugin Job Queue en tiens compte, et une simple mise a jour suffira à corriger le probleme. La page d'administration ecrire/?exec=job_queue propose aussi un bouton pour purger la file et la réinitialiser.

Cache Cool

excuse-moi il manquait un point d'interrogation, la page d'admin est : ecrire/?exec=job_queue
Je vais ajouter un bouton de purge sur cette page, ce sera le plus simple, car manipuler la base en SQL est tojours risqué. Sinon, le mieux serait de me donner un accès admin à ton site, pour que je regarde ce qui se passe et pourquoi la file ne se vide pas correctement. Tu peux m'envoyer ton email via le formulaire de contact de SPIP-contrib si tu le souhaires, afin qu'on gère cela en direct.

Cache Cool

Bonjour,
Merci de te pencher sur mon problème.
Voici mon site : www.inkd.eu.
Pour info, j'en suis à plus de 8600 lignes dans ma table spip_jobs, chacune pesant entre 2 et 4 Ko (soit à peu près la taille max de ma bdd).
Je suis sous Spip 2.1, Cache_cool 0.2.4 et job_queue 0.6.2.
Je ne suis pas parvenu à vider manuellement la table en passant par ecrire/exec=job_queue (erreur 404). L'alternative c'est bien de supprimer les lignes dans la table via PhpMyAdmin. Aucun risque ? (je suis un total nb en MySql).

Cache Cool

Bonjour, la table des jobs ne doit jamais rester volumineuse : elle est censée se vider en moyenne aussi vite qu'elle ne se remplit.
Si la table ne se vide pas ou se maintient à un niveau élevé, cela montre peut être un problème de stratégie de vidage des jobs et cela peut être embètant.
Il est toujours possible de vider la table manuellement, en repassant ensuite sur la page d'aministration ecrire/exec=job_queue pour réinitialiser la file.

Cela dit, si ta file remonte à un niveau élevé rapidement, je suis intéressé pour avoir un accès à ton site et voir quel est le scenario qui empêche la file de se vider. Utilise-tu bien une version >= 2.1 de SPIP ainsi qu'une version à jour des plugin job_queue et cache_cool ?

Cache Cool

Hello,

J'ai exactement le même soucis. Ma bdd occupe 90% de l'espace autorisé par mon hébergeur et ça commence à devenir franchement problématique. Peut-on vider cette table jobs sans risque ?
D'avance merci pour votre aide :)

Cache Cool

Hello Cédric

Vu que le plugin est nécessite spip 2.1, je peux rajouter ce necessite dans plugin.xml simplifier la description ?

Cache Cool

Bonjour,

depuis que j'ai installé Cache Cool, le site est beaucoup plus rapide qu'auparavant c'est super.
Le seul bémol, c'est que j'ai une base qui grossit... grossit.

Aujourd'hui la table spip_jobs dans mysql pèse pas moins de 100mo
>> 22 495 lignes et 103,9 Mo

Est-ce normal ou ais-je fait une bétise ?

Merci à tous d'éclairer ma lanterne car j'ai 250 mo de base et je ne voudrais pas planter le site si ca dépasse le quota ;-)

Cache Cool

Ah, effectivement, des références sont bien apparues depuis mon dernier post, et ça ressemble à ça :

Nov 08 07:38:50 209.44.112.96 (pid 20781) queue: public_produire_page() start
Nov 08 07:38:51 209.44.112.96 (pid 20781) queue: public_produire_page() end
Nov 08 07:38:53 209.44.112.96 (pid 10331) queue: public_produire_page() start
Nov 08 07:38:53 209.44.112.96 (pid 10331) queue: public_produire_page() end
Nov 08 07:38:53 209.44.112.96 (pid 10331) queue: public_produire_page() start
Nov 08 07:38:53 209.44.112.96 (pid 10331) queue: public_produire_page() end

Mais à partir de quel trafic dois-je considérer que ce plugin peut m'être utile ? Le site en question reçoit 10000 visites par mois. C'est pas assez ?

Cache Cool

En fait, sur les sites a faible trafic, on a pas le temps de voir apparaîtres les jobs sur la page dédiée.
Il faut regarder le fichier tmp/queue.log pour voir si tu y vois bien public_produire_page

Cache Cool

Bonjour,
avec un Spip tout frais passé à 2.1.2 + les plugins jobqueue et cachecool installés et activés, la page ?exec=job_queue ainsi que tmp/queue.log ne m'affichent aucune référence public_produire_page.

Ai-je oublié de faire quelque chose ?

Cache Cool

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.

Cache Cool

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.

Cache Cool

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.

Cache Cool

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 ?

Cache Cool

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ù.

Cache Cool

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 job public_produire_page.

Cache Cool

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.

Cache Cool

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.

Cache Cool

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 ?

Cache Cool

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.

Cache Cool

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

Cache Cool

est-ce que tu pourrais poster le patch, cela m'intéresse, merci

Cache Cool

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.

Cache Cool

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 ?

Cache Cool

« 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 ?

Cache Cool

C'est possible en théorie, à vérifier et confirmer, car on entre là dans un domaine sensible.

Cache Cool

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.

Cache Cool

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

Super !!!

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

Test de fonctionnement

la procédure de test est vide

J'ai rien dit ...

Ca semble marcher

Test de fonctionnement

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

Cache Cool

Cool ça - je l'ai installé et je surveille un peu ce qui se passe... Dans mon job queue il n'y a pas de recalcul de squelettes en vue, mais c'est peut-être parce que j'ai déjà ralentie le recalcul des caches en déléguant la fonction au couteau suisse.

Côté site public, ça fuse bien.

Côté serveur difficle à dire.

Merci pour tous ces progrès :-)

Cache Cool

c'est Cool ca :D

Cache Cool

Ça marche bien car SPIP ouvre une session visiteur, et dans ce cas Cache Cool sert le cache réchauffé uniquement, donc à jour.

Cache Cool

ça marche comment quand on répond à un forum ?