Cache Cool

Le plugin cache cool accélère le service des pages en différant le calcul du cache lorsque c’est possible pour éviter à l’internaute d’attendre après.

Il sert donc le cache « froid », et le réchauffe en cuisine pour la prochaine fois qu’il sera demandé.

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.

Notes

[1Précision pour développeurs : Quand un squelette utilise des globales non officielles pour changer son état et ce qu’il affiche, il convient de les déclarer dans une constante PHP _CACHE_COOL_GLOBALS_TO_SAVE pour permettre a cache_cool de les sauvegarder/restaurer a chaque calcul de cache asynchrone.

Discussion

23 discussions

  • 2

    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

    • 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

    • 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

    Répondre à ce message

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

    Répondre à ce message

  • 11
    LaVacheFolle

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

    • François

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

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

    • François

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

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

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

    • 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 ?!

    • 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

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

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

    • 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’.

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

    Répondre à ce message

  • 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é ?

    Répondre à ce message

  • 4

    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.

    • Personne n’a observé ce problème ?

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

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

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

    Répondre à ce message

  • Salut,

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

    Répondre à ce message

  • 2

    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.

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

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

    Répondre à ce message

  • 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

    Répondre à ce message

  • 1

    Hello Cédric

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

    Répondre à ce message

  • 2
    martingranger

    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 ?

    • 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

    • martingranger

      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 ?

    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 :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

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.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom