SPIP-Contrib

SPIP-Contrib

عربي | Deutsch | English | Español | français | italiano | Nederlands

286 Plugins, 197 contribs sur SPIP-Zone, 241 visiteurs en ce moment

Accueil > Optimisation et performances > Cache Cool > Cache Cool

Cache Cool

31 octobre 2009 – par Cerdic – 54 commentaires

40 votes

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 svn, à l’adresse svn ://zone.spip.org/spip-zone/_plugins_/cache_cool, 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.

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 vielle 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. Mais il faut veiller à avoir un $quota_cache suffisamment grand dans le fichier mes_options.php.

J’utilise en général l’initialisation suivante dans mes_options.php :

ce qui permet de déclarer une taille de cache de 100Mo au lieu de 10Mo (valeur par défaut).

Voir en ligne : http://plugins.spip.net/cache_cool

Dernière modification de cette page le 10 juin 2015

Retour en haut de la page

Tout afficher

Vos commentaires

  • Le 10 mars à 12:38, par Théo En réponse à : 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.

    Répondre à ce message

  • Le 28 novembre 2010 à 15:48, par LaVacheFolle En réponse à : 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 ;-)

    • Le 6 janvier 2011 à 09:13, par François En réponse à : 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 :)

    • Le 6 janvier 2011 à 09:44, par Cerdic En réponse à : 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 ?

    • Le 6 janvier 2011 à 11:09, par François En réponse à : 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).

    • Le 6 janvier 2011 à 11:37, par Cerdic En réponse à : 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.

    • Le 7 janvier 2011 à 11:42, par Cerdic En réponse à : 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.

    • Le 8 novembre 2011 à 16:12, par Billou En réponse à : 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 ?!

    • Le 5 novembre 2015 à 12:16, par Syd En réponse à : 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

    • Le 5 novembre 2015 à 12:36, par Billou En réponse à : Cache Cool

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

    • Le 5 novembre 2015 à 15:17, par Syd En réponse à : 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.

    • Le 16 décembre 2015 à 12:38, par goony En réponse à : 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’.

    • Le 10 février à 15:22, par Syd En réponse à : 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 ?

    Répondre à ce message

  • Le 31 mai 2015 à 21:04, par Maïeul En réponse à : 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é ?

    Répondre à ce message

  • Le 4 janvier 2013 à 18:29, par g0uZ En réponse à : 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.

    • Le 16 février 2013 à 09:14, par g0uZ En réponse à : Cache Cool

      Personne n’a observé ce problème ?

    • Le 16 février 2013 à 12:26, par Cerdic En réponse à : 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.

    • Le 24 février 2013 à 16:45, par Cerdic En réponse à : Cache Cool

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

    • Le 9 mars 2013 à 11:44, par g0uZ En réponse à : Cache Cool

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

    Répondre à ce message

  • Le 10 mai 2015 à 10:43, par martina En réponse à : Cache Cool

    Salut,

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

    Répondre à ce message

  • Le 10 juillet 2012 à 15:55, par Artlogic En réponse à : 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.

    • Le 10 juillet 2012 à 16:24, par Cerdic En 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.

    • Le 10 juillet 2012 à 17:29, par Artlogic En réponse à : 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.

    Répondre à ce message

  • Le 27 janvier 2012 à 14:01, par LudoRA En réponse à : 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

    Répondre à ce message

  • Le 23 décembre 2010 à 18:45, par Yffic En réponse à : 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 ?

    • Le 7 janvier 2011 à 11:42, par Cerdic En réponse à : Cache Cool

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

    Répondre à ce message

  • Le 8 novembre 2010 à 12:59, par martingranger En réponse à : 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 ?

    • Le 8 novembre 2010 à 13:11, par Cerdic En réponse à : 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

    • Le 8 novembre 2010 à 14:02, par martingranger En réponse à : 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 ?

    Répondre à ce message

  • Le 17 octobre 2010 à 17:15, par LudoRA En réponse à : 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.

    • Le 17 octobre 2010 à 18:12, par Cerdic En réponse à : 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.

    • Le 17 octobre 2010 à 21:24, par LudoRA En réponse à : 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ù.

    • Le 17 octobre 2010 à 22:09, par Cerdic En réponse à : 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 ?

    • Le 18 octobre 2010 à 09:40, par LudoRA En réponse à : 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.

    • Le 18 octobre 2010 à 10:00, par Cerdic En réponse à : 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.

    • Le 18 octobre 2010 à 10:05, par Maïeul En réponse à : 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.

    Répondre à ce message

Répondre à cet article

Qui êtes-vous ?

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 Les choses à faire avant de poser une question (Prolégomènes aux rapports de bugs. )
Ajouter un document

Retour en haut de la page

Ça discute par ici

  • Métas +

    3 décembre – 14 commentaires

    Améliorez l’indexation de vos articles dans les moteurs et leur affichage sur les réseaux sociaux grâce aux métadonnées Dublin Core, Open Graph et Twitter Card. Installation Activer le plugin dans le menu dédié. Dans le panel de configuration, (...)

  • Adaptive Images

    15 novembre 2013 – 69 commentaires

    Un plugin pour permettre aux sites responsive d’adapter automatiquement les images de la page à l’écran de consultation. Adaptive Images, que l’on pourrait traduire par Images adaptatives, désigne la pratique qui vise à adapter les taille, (...)

  • Social tags

    8 septembre 2008 – 428 commentaires

    Le plugin Social Tags permet d’ajouter des icônes de partage de liens vers les sites tels que Digg, Facebook, Delicious.... Une fois le plugin installé et activé (voir doc.), le choix des sites se fait via un menu de configuration. Insertion (...)

  • Module de Paiement Stripe

    17 octobre – commentaires

    Stripe est un prestataire de paiement externe https://stripe.com/fr qui propose une API moderne et une interface de paiement extrêmement conviviale et efficace. Ce module permet les paiements à l’acte et les paiement récurrents. Configuration (...)

  • Métas

    8 août 2009 – 50 commentaires

    Ce petit plugin permet l’ajout, depuis l’espace privé, de metatags aux articles et rubriques de SPIP, ainsi que la mise en exergue de mots importants.

Ça spipe par là