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

  • 6

    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 job public_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

  • 1

    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

  • 1

    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

    Répondre à ce message

  • 1

    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.

    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

  • 1

    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

  • 1

    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

    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