Refresher

This contribution or plugin is actually being tested. Issues may occur, don’t hesitate to report those in following post’s comments.

Ce plugin vise à rendre votre site un maximum statique, en permettant des temps de cache extrêmement longs et en rafraîchissant de manière ciblée les pages du site en cas d’action éditoriale.

Les pages à rafraîchir seront mises dans une file d’attente (à l’aide du Job Queue), et rafraîchies une par une en tâche de fond sur le serveur, ou bien lors de leur prochaine visite.

Les avantages de ce plugin

-  permettre de définir des temps de cache tres longs dans les squelettes, et eviter de rafraichir régulièrement des squelettes expirés “par vieillesse” (utilisation non nécessaire des ressources du serveur).
-  permettre de rafraichir uniquement les caches concernés par des modification du site.
-  optionellement rafraichir les pages en tâches de fond, et non pas devant les utilisateurs.
-  rafraichir les pages nécessaires en temps voulu. Si un article est programmé à la publication dans le futur, on rafraichira les pages affectées à ce moment précis.

Il propose de plus quelques outils pratiques pour éliminer des éléments du cache de manière ciblée.

Pour ceux qui utilisent un fournisseur de CDN, ce plugin intègre une invalidation chez Cloudflare, Edgecast et Akamai. Pour ceux qui n’en utilisent pas (ce qui doit être le cas en général), il vous suffira d’ignorer les parties qui mentionnent le CDN.

Ce plugin, associé à une bonne connaissance et organisation de vos squelettes, permet un taux de rafraichissement de votre site optimal. Il est principalement destiné aux sites à gros traffic et/ou à vaste contenu, qui ne peuvent pas se permettre de repartir à zéro de façon régulière en terme de cache.

Principe des systèmes Pull/Push

Ce plugin permet d’invalider les pages du site de deux façons: en mode “Pull” ou “Push”, qui peuvent être utilisées conjointement sur un même site, pour des jeux de page différentes :
-  La technique “Pull” consiste en une invalidation des pages (via leurs URLs), et l’attente de la prochaine visite sur ces pages pour reconstruire leur cache (devant le visiteur). Le cache est ici construit à la demande.
-  En mode “Push” on va recalculer la page en tache de fond, sans nécessairement que la page soit visitée. Ainsi dans cette méthode nous forçons un calcul du cache afin que les visiteurs éventuels profitent d’un cache déjà prêt, même lors de la première visite qui suit l’invalidation.

IMPORTANT:
-  Pour le “Pull”, il suffit de connaître le nom du squelette principal des pages et de l’objet invalidé.
-  Pour le “Push”, il faut être en mesure de déterminer exactement les URLs des pages a invalider.

La méthode “Pull” est utile quand:

-  il est difficile de déterminer les URLs à modifier (car le “Push” nécessite de connaître les URLs exacts)
-  on a un très grand nombre d’URLs à invalider (ne pas charger le job_queue avec un tas de pages a calculer)
-  les pages à invalider sont rarement visitées et/ou invalidées tres fréquemment (peu de chances de visite entre deux invalidations, evitons de pre-calculer pour rien).
-  il importe peu si les pages sont recalculées devant le visiteur (un bot?)

La méthode “Push” est utile quand:

-  on a peu d’URLs à invalider et on peut les déterminer précisément
-  les pages sont assez lourdes à calculer, (mais pas trop nombreuses) afin d’ éviter une longue attente pour le prochain visiteur.
-  les pages concernées sont fréquemment visitées (si on est certain qu’une page va être visitée, autant la préparer).
-  on veut contrôler la charge du serveur, car les pré-calculs sont gérés par le job_queue, et à une fréquence définie dans la configuration du plugin.

Cas typique d’utilisation du ’Pull’:

Une rubrique paginée qui doit etre intégralement invalidée, dont la liste d’URLs est difficile a déterminer (ou la pagination s’arrête-t’elle?), et peut-être longue. De plus, en général, plus on avance dans la pagination et moins une page a de chances d’être visitée. Il se peut qu’un grand nombre de ces pages ne soient même pas visitées avant la prochaine invalidation de cette rubrique.

Cas typique d’utilisation du “Push”:

La page d’accueil du site.

Installation

Ce plugin s’installe classiquement, et ne nécessite aucun autre plugin. Une fois le plugin activé, l’invalidation globale du site après une action éditoriale sera désactivée (celle utilisée par défaut dans SPIP). Les rafraichissements ne prendront toutefois effet qu’une fois ceux-ci configurés dans la page de configuration du plugin.

Le plugin utilise job_queue afin de gérer la file d’URLs à rafraichir, mais job_queue est maintenant integré à SPIP depuis la version 3.0.

Le plugin est compatible avec le CacheCool, mais il en limite l’utilite.

Options basiques

- autoriser le plugin à effectuer des rafraichissements de cache SPIP (Push).

Cette option va faire en sorte que les URLs soient recalculés afin de rafraichir le contenu de leur page. Pour cela nous traitons chaque URL dans la file en la chargeant à l’aide de la librairie PHP CURL (qui doit être installée sur votre serveur si vous utilisez cette option). Le paramètre var_mode=calcul est passé avec la methode POST. Cela nous permet de passer au travers du CDN dans le cas ou vous en utilisez un.

- autoriser le plugin à faire des purges sur le CDN, si vous en utilisez un.

Cloudflare, Akamai et Edgecast proposent des API pour effectuer des purges de cache ciblées. Nous pouvons ainsi invalider un URL en particulier, ce qui ne mettra que quelques secondes à prendre effet sur les serveurs du CDN. Il suffit de fournir les informations demandées dans la page de configuration. Ces informations vous sont fournies par votre prestataire CDN. L’utilisation de la purge CDN nécessite l’extension CURL pour PHP. Vous pouvez utiliser la purge CDN sans utiliser le rafraichissement du cache SPIP si vous le souhaitez (et si cela a du sens dans votre configuration).

- Liste de groupes de mots clés à rafraichir.

Nous vous demandons de sélectionner les groupes de mots clés dont les mots clés possèdent leur propre page sur le site, afin de ne pas mettre à jour des pages de mots clés qui n’existent pas. Nous partons du principe que les mots clés d’un même groupe ont le même comportement et que cette sélection est suffisante.

- Qui peut utiliser var_mode=recalcul dans les URLs?

Pourquoi cette option? Pourquoi pas? Vous ne souhaitez peut être pas que n’importe qui puisse recalculer vos pages. Et si pour une raison obscure Google se mettait à crawler votre site en utilisant ce paramètre?

- Temps de pause entre chaque rafraichissement (Push).

Il est recommandé de mettre un temps de pause, même faible, entre les rafraichissements, afin de ne pas créer de subite surcharge du serveur. Ceci est important si vous utilisez le rafraichissement du cache SPIP (calcul), si des actions éditoriales entrainent le rafraichissement de nombreux URLs et si certaines de ces pages ont des calculs lourds. De plus, certains CDN ont un nombre limite de requetes vers leur API par minute.

Créer des règles d’invalidations de type ’Pull’

La méthode de “Pull” utilise une table dans la base de données. Elle se remplira d’URLs de votre site une fois que vous aurez créé des règles de type “Pull”. Dans refresher_options.php, il faut créer une variable globale, qui est un tableau de règles. Une règle consiste en un squelette (le squelette principal d’une page) et d’un objet. Dès lors, si on tombe sur une page qui utilise ce squelette et cet objet, soit cet URL est déjà dans la table (cache valide), soit il est absent, et on enregistre l’URL dans la table et recalcule les caches. Lors des invalidations, nous retrouvons toutes les pages liées à un objet et on les supprime de la table.

Prenons un exemple. Nous souhaitons être capables d’invalider les pages liées a un mot clé si on ajoute un article à ce mot. Dans ce cas, il faut créer la règle suivante:

$GLOBALS['refresher_objets'] = array(
array('mot_skel','mot')
);

Dans mon système, la page d’un mot clé utilise le squelette “mot_skel”. Ainsi, dès que l’on tombera sur l’une de ces pages, on enregistre l’URL ainsi que l’id_mot associé à cet URL. Lors d’une invalidation, il suffira d’indiquer au plugin de rafraîchir les mots associés aux articles, et l’ajout d’un article va invalider toutes les URLs des mots associés à cet article. Il est à noter que les objets peuvent être des objets non-SPIP, et les identifiants peuvent être des chaines de caractères.

Rafraichissements simples (mode Push)

La page de configuration du plugin permet de sélectionner des rafraichissements simples et qui me paraissent les plus évidents. Nous pourrons améliorer cette liste avec les impressions des utilisateurs, mais fournir une liste infinie de cas de figures et de liens possibles à rafraichir n’est pas le but, car avec un peu de PHP nous pouvons cibler de manière tres précise nos besoins en rafraichissements et personaliser ce plugin (voir “Rafraichissements avancés”). Pour ma part je n’utilise aucune de ces options à cocher.

Rafraichissements avancés

Le plugin possède un système similaire aux pipelines SPIP, ainsi pour chaque action éditoriale, nous pouvons créer une fonction PHP qui prendra en paramètre un tableau d’URLs, et retourne ce même tableau une fois qu’on lui aura ajouté nos URLs à rafraichir. Il est soit possible d’ajouter directement des URLs a ce tableau, soit des associations “id_objet|objet” (chaine de charactères sous cette forme).

Push:

-  URL -> va rafraichir cet URL dans le job_queue
-  id_objet|objet -> va rafraichir l’URL de cet objet (ce que retournerait la balise #URL_XXXXXX, par exemple #URL_MOT)

Pull:

-  URL -> va invalider cet URL specifique, si il est dans le système
-  id_objet|objet -> va chercher tous les URLs du système qui correspondent a cet objet si on lui a defini des regles de ’Pull’

Ainsi, si vous avez des besoins très particuliers en matière de mises à jour lors de l’édition d’un article (édition d’un champs, par exemple), vous pouvez créer une fonction “refresh_objet_modifier_article”, soit dans mes_fonctions.php ou dans refresher_options.php, ou encore refresher_functions.php (assurez vous juste de faire au mieux pour votre propre organisation). Cette fonction aura cette allure:

function refresh_objet_modifier_article($urls, $id_article, $arr){
   ...
   //insertion de mes URLs à rafraichir dans $urls
   ...
   return $urls;
}

À l’intérieur de cette fonction, il vous suffira de réccupérer les URLs que vous souhaitez rafraichir, en considérant que la connaissance de l’identifiant de l’article qui est modifié vous le permet.

Si par exemple, je souhaite rafraichir la page de la rubrique de l’article ainsi que la homepage:

function refresh_objet_modifier_article($urls, $id_article, $arr){
   // rafraichir la rubrique en “Push” 
   $res = sql_select("id_rubrique", "spip_articles", "id_article=".intval($id_article), "", "", 1);
   if($row = sql_fetch($res)) array_push($urls['push'], $row['id_rubrique'].'|rubrique');
 
   //rafraichir la homepage (url vide ou “/”) en “Push”
   array_push($urls['push'],'');
 
   //rafraichir l'article en “Pull” 
   array_push($urls['pull'], $id_article.'|article');
 
   return $urls;
}

À noter que le paramètre $arr contient les informations de mise à jour interceptées dans les pipelines post_edition et pre_edition (c’est exactement le même paramètre que celui passé à ces pipelines). Vous pouvez analyser le contenu de ce tableau pour faire des rafraichissements encore plus pointus si vous le souhaitez.

Rafraichir la rubrique de l’article lors de sa modification est disponible depuis la page de configuration dans les rafraichissements basiques, ce code est juste à titre d’exemple. Si toutefois pour une raison ou une autre le même URL apparaît plusieurs fois dans le processus, les doublons seront éliminés et l’URL ne sera rafraichi qu’une seule fois.

voici une liste des fonctions principales que vous pouvez créer (il y en a d’autres non listées, et d’autres à venir) . Elles fonctionnent toutes sur le modèle évoqué plus haut:

refresh_objet_instituer_article($urls, $id_article, $arr)


-  > traite le changement de statut d’un article ainsi que son changement de date. En gros cela correspond a la publication/suspension d’un article sur le site.

refresh_objet_modifier_article($urls, $id_article, $arr)
refresh_objet_modifier_document($urls, $id_document, $arr)
refresh_objet_modifier_rubrique($urls, $id_rubrique, $arr)
refresh_objet_modifier_mot($urls, $id_mot, $arr)


-  > à priori tout autre objet éditable fonctionnera de la même manière, à tester...

refresh_lien_delete_document_article($urls, $id_document, $id_article, $arr)
refresh_lien_insert_document_article($urls, $id_document, $id_article, $arr)


-  > à priori tout autre objet associable à un document fonctionnera de la même manière, à tester...

refresh_lien_delete_mot_article($urls, $id_mot, $id_article, $arr)
refresh_lien_insert_mot_article($urls, $id_mot, $id_article, $arr)


-  > à priori tout autre objet associable à un mot fonctionnera de la même manière, à tester...

Outils de nettoyage du cache

Les points suivants concernent le second onglet dans la configuration du plugin. Il s’agit de quelques outils partiques pour gérer le cache.

- Vider la file d’attente d’URLs à rafraichir

Cette fonctionnalité permet de vider la file d’attente des URLs à rafraichir dans le job_queue.

- Supprimer des fichiers cache SPIP en fonction de leur nom

Cette fonction peut s’avérer plus intéressante qu’elle n’en a l’air. Elle permet dans un premier temps de vider les répertoires du cache un par un, ce qui peut être pratique si l’on souhaite purger le cache mais de manière légèrement progressive afin de ne pas avoir subitement tout le site à reconstruire. Plus subtilement encore, elle permet dans certains cas de supprimer les caches correspondant à un squelette en particulier. En effet dans certains cas, le système de nommage des fichiers cache nous permet d’identifier quel squelette ils contiennent. Les fichiers cache sont nommés de maniere peu lisible mais avec une certaine logique, à partir du nom de squelettes et des paramètres, entre autres.

Prenons un exemple concret sur mon site, j’ai un squelette article.html, et avec un peu de manipulation PHP je me suis aperçu que sur une page prise au hasard le nom de fichier généré est ’art-mar-ast-mar-rap-s-ar-2bea7d03’:

-  le ’art’ de debut correspondant au nom du squelette article.html
-  la suite étant générée à partir du titre de l’article et les caracteres de fin sont le résultat d’un calcul md5

Il se trouve que cette logique s’applique à tous mes articles similaires à cette page, ainsi je peux supprimer tous ces caches en utilisant la fonction du backend et en mettant dans le champs le nom de fichier “art-*”.

Il est ainsi possible de supprimer des caches correspondants à certains squelettes ou certains parametres sans pour autant avoir à purger tout le cache du site. Cela demande un peu d’astuce mais s’avère pratique.

- Supprimer des fichiers cache SPIP en fonction de leur date

Ceci est une autre fonction extrêmement utile si l’on ne peut pas se permettre de se débarrasser de son cache. Prenons le simple exemple où vous vous rendez compte après plusieurs jours que vous avez fait une erreur significative dans vos squelettes. Cette erreur s’est maintenant répandue dans vos caches et soit vous attendez que vos pages se rafraichissent naturellement (laissant donc l’erreur trainer un certain temps), soit vous purgez votre cache et votre serveur va prendre une charge que vous auriez volontiers évité. Il suffit d’utiliser cette fonction pour supprimer tous les caches créés pendant la période entre la mise à jour malencontreuse et le moment présent. Votre site est donc nettoyé avec un impact minimum sur votre serveur.

- Rafraichir un URL manuellement

Suivant les options activées dans le premier onglet du plugin, cela vous permet de manière ponctuelle de rafraichir une page dans le cache SPIP et/ou purger l’URL sur le CDN. Pour ce qui est de mettre a jour le cache SPIP, cela revient à taper manuellement “var_mode=calcul” dans votre URL. Mais cela est très pratique lorsque vous utilisez un CDN car vous pouvez ainsi pour n’importe quelle raison invalider l’URL que vous souhaitez sur les serveurs du CDN (cela prendra plusieurs secondes avant d’être effectif sur tous les serveurs du CDN). Un autre cas de figure est si vous n’autorisez pas l’utilisation de la variable “var_mode=(re)calcul” sur le site public. Cette fonctionnalité passe au travers car elle envoie le “var_mode=calcul” dans une variable de type POST.

Rafraichissements réguliers

Il s’agit ici du troisième onglet de la configuration du plugin. Cette fonctionalité permet de programmer à intervalles reguliers des mises a jour de certaines pages (en “Push”). Le temps d’intervalle est à définir en minutes. La marge d’erreur est de 5 minutes, c’est à dire qu’en pratique, un intervalle entre deux rafraichissements d’URLs peut être jusqu’à 5 minutes plus long que la valeur définie par l’utilisateur. Ceci est du au fait que la tâche de fond principale du plugin ne s’effectue que toutes les 5 minutes afin de ne pas encombrer la file.

Optimisations et remarques

Ce systeme est créé afin d’éviter de générer des rafraichissements inutiles. Par exemple si un article est modifié mais n’est pas encore publié sur le site (on teste le statut et la date), le système n’effectuera pas de rafraichissement. Si un article est programmé pour une publication, cela entrainera des rafraichissements à la date précise de cette publication. Mais si l’on modifie cette date par la suite, les rafraichissements programmés precedemment seront annulés et de nouveaux seront enregistrées dans job_queue avec la nouvelle date. Gérer tous ces cas est toutefois complexe et il est possible que des cas de figure aient été négligés à ce jour.

C’est à la responsabilité du programmeur de cibler de maniere précise ces rafraichissements lors de l’utilisation des pipelines afin de ne pas charger inutilement le serveur. Il est de plus recommandé de préparer ses articles au maximum à l’avance (contenu, documents, mots clés) et de programmer la publication au dernier moment, ce qui limitera les risques de laisser passer des mises à jour.

Astuce pour rafraichir un bloc isolé

Il se peut que vous veuillez rafraichir un bloc sans connaître sa position dans votre site, mais en connaissant ses paramètres. Un cas concret serait un bloc article dans une rubrique qui a une pagination.

rubrique.html:

...
<BOUCLE_page(ARTICLES){id_rubrique}{par date}{inverse}{pagination 10}>
    ...
    <INCLURE{fond=bloc_article}{id_article}{parametre1}{parametre2}>
    ...
</BOUCLE_page>
...

Dans le cas de la modification d’un article, vous voulez rafraichir ce bloc, mais pas toutes les pages de la rubrique (charge inutile, voire insupportable si la rubrique est vaste). Il suffit de créer un squelette dédié au rafraichissement de ce bloc, en vous assurant simplement que tous les paramètres sont identiques et repris dans le même ordre, afin de mettre à jour le bon fichier en cache.

refresh_bloc_article.html:

<INCLURE{fond=bloc_article}{id_article}{parametre1}{parametre2}>

Vous pouvez placer ce squelette dans votre répertoire squelettes, ou bien dans la racine du repértoire du plugin refresher, puisque ce squelette fait en quelques sortes partie du plugin.

Ainsi il ne vous restera qu’à écrire ce code dans le pipeline:

function refresh_objet_modifier_article($urls, $id_article, $arr){
   array_push($urls['push'], "spip.php?page=refresh_bloc_article&id_article=".$id_article);
   return $urls;
}

Puisque le squelette refresh_bloc_article.html utilise exactement le même bloc_article que rubrique.html, il va écraser le cache, et peu importe où le bloc se trouve dans votre pagination il sera à jour sans que l’on ait à se soucier de recalculer les pages de la rubrique. Cela est d’autant plus pratique si ce bloc_article figure dans plus d’une rubrique, car vous pouvez tout mettre a jour en un seul rafraichissement d’URL.

Ce plugin est toujours en construction. Toutes suggestions ou découvertes de cas particuliers qui passent au travers du système sont les bienvenues afin de perfectionner ce plugin.

J’ai affiché une compatibilité à SPIP 3.0 car c’est le systeme sur lequel je l’ai développé. Il est possible qu’il soit compatible à SPIP 2.X, mais je ne l’ai pas essayé. La compatibilité avec d’autres plugins est aussi à mettre à l’épreuve. J’ai rapidement testé avec le plugin “crayons” sur un document sans succès.

updated on 16 July 2020

Discussion

3 discussions

  • Merci Goony.

    Ça devrait être utile à beaucoup de monde.
    Ajuster un squelette sur un site en production ne devrait pas impacter les visiteurs qui arrivent après.

    Gdf

    Reply to this message

  • 17

    Bonjour
    une version spip 3.2 est elle prévue ? si non pensez vous qu’il soit compatible ?
    Merci
    Natacha

    • Bonjour,
      Avez-vous pu faire un essai en 3.2 ?
      Merci

    • nous utilisons ce plugin en ce moment sur la derniere version de spip.
      nous travaillons toujours a son developement et mise a jour.
      la version ici presente n’est pas la toute derniere mais elle devrait marcher avec la derniere version de spip.

      je vais aller voir a uploader la derneire version sur la contrib.

    • Ok philooo

      Je viens de réaliser que Spip invalide par défaut toutes les pages après l’édition d’une seule.
      Ai-je bien compris? Est-ce simplement une implémentation historique, ou y a-t-il des raisons pratiques à ce choix ?

      Ce plugin est donc plus que bienvenu pour améliorer la gestion du cache.

      Merci

      Gdf

    • cette invalidation du site complet apres chaque mise a jour editoriale est intolerable en effet ;) c’est pour cela que nous avons creer ce plugin.

      je ne me rappel plus quand cette invalidation generique a ete mis en place, mais ce n’etait aps le cas au debut de spip.

      le cache spip est passe par plusieurs systeme tres different. au debut il y avait un system de base de donnee et d’invalidation, et c’est system que nous avons essaye de recreer, de facon un peu plus sophisitque.

      avec notre system, nous pouvons gerer un site tres large , plus de 100,000 articles, avec un tout petit server, vu qu’une fois une page calcule, nous ne la recalculons plus, a moins qu’elle soit ’lie’ a une mise a jour recente.

      ce system reduit enormement les ressources server ET SURTOUT permet de creer des pages lourdes en calcul cpu, sans crasher le system vu qu’on les cree en file d’attentes.

      je pense que c’est la seule facon de faire pour etaler et reduire les besoins de processing du server.

    • Ce plugin apporte de bonnes solutions, c’est clair.

      J’ai quelques questions:

      l’interface propose un choix :
      -  Voulez-vous utiliser le rafraichissement SPIP (recalcul)?
      Quelle est la conséquence du choix ?

      -  Je comprends que le plugin traite les cas d’éditions
      Mais pour mon cas il faudrait que s’il y a recalcul manuel un push soit fait d’une liste d’Url choisies.
      Mais, est-ce le cas pour le recalcul en mode manuel en mode push ?

      -  Il y a un choix d’ajustement des droits de calcul/recalcul (- Qui peut utiliser var_mode=calcul/recalcul dans les URLs?)
      mais actuellement si je comprends bien pour SPIP le calcul est possible pour tout le monde et le recalcul pour les administrateurs.
      Ceci me convient. Mais l’interface affecte le même droit aux deux cas> calcul et recalcul.
      Je ne vois pas de choix possible pour garder le fonctionnement original.
      Est-ce possible?

      Merci

      Gdf

    • Bonjour,

      1. “- Voulez-vous utiliser le rafraichissement SPIP (recalcul)?”

      Ce n’est pas suffisament explicite, en effet. Mais ca active le recalcul des pages en mode “push”. A priori il n’y a aucune raison pour ne pas activer cette option, si ce n’est avoir seulement des purges CDN sans toucher au cache SPIP des pages. Mais je ne vois pas dans quelles circonstances on voudrait cela.

      2. Un recalcul manuel n’enclenche pas le refresher. Cela va simplement rafraichir la page en cours. Est-ce que tu veux simuler une action editoriale quand tu fais un recalcul, afin de lancer le refresher? Il est possible d’intercepter les parametres de l’URL dans mes_options.php ou refresher_options.php puis il faudrait re-creer une partie du tableau passe en parametre au pipeline post_edition et appeler la fonction refresher_post_edition($arr). C’est un peu tricky mais si tu sais faire du PHP tu devrais t’en sortir.

      3. Pour le calcul/recalcul, tout ce que le plugin fait est DESACTIVER le calcul/recalcul en fonction de ce choix. Je ne savais pas que seuls les auteurs par defaut pouvaient faire un recalcul. Donc activer l’option “tout le monde” a pour consequence que le plugin n’intervient pas dans le fonctionnement original de SPIP. Je vais corriger la description bientot.

      PS: Nous avons maintenant une version tres differente de ce plugin. Nous l’avons tune pendant plusieurs annees afin de ne rafraichir que les pages necessaires sur notre site et rien de plus. Nous avons retire des fonctionalites trop generiques et ajoute pas mal de patches pour le rendre compatible avec d’autres plugins de gestion du cache que nous utilisons. Je suis en train de comparer cette version du plugin avec la notre et je vais poster le nouveau plugin prochainement. Je creerai un nouvel article car la description du plugin sera trop differente pour utiliser la meme page, et je ne veux pas supprimer cette version du plugin au cas ou elle est plus adequate pour certains utilisateurs.

      Nous avons aussi un autre plugin qui n’est possible que grace au plugin “refresher”. Il s’agit du plugin “cache statique” qui enregistre les caches de nos pages HTML en entier dans le repertoire cache. Nous servons directement nos caches HTML sans meme initialiser SPIP, et nous rafraichissons toutes nos pages avec la methode “push” du refresher. Le cache traditionel de SPIP ne nous sert plus a rien. Il n’y a aucun systeme plus rapide pour servir les pages, sauf peut etre si on utilisait un truc du genre memcached pour enregistrer nos caches HTML (mais on a tellement de pages que notre memoire vive n’est pas assez grande pour tout contenir).

    • “Est-ce simplement une implémentation historique, ou y a-t-il des raisons pratiques à ce choix ?”

      Par le passe (avant SPIP 2.0, je crois) SPIP utilisait un systeme pour invalider les caches de maniere ciblee. Chaque noisette du site (chaque bloc de chaque page) avait une ligne dans la table spip_caches. Cette ligne nous indiquait entre autres le nom du fichier cache sur le disque, ainsi que sa validite et date d’expiration. Ce systeme permettait de ne rafraichir que les blocs qui en avaient besoin. Mais c’etait un systeme qui avait un enorme cout en performances, et qui a ete abandonne et remplace par l’invalidation totale du site. Enfin c’est comme cela que je m’en souviens.

      Le refresher s’inspire de cet ancien systeme avec la methode “pull”. Mais au lieu d’enregistrer un tas d’information pour chaque noisette du site, on a moins d’informations et uniquement pour les URLs. Cela fait une table moins lourde, et qui n’est consultee qu’une fois par page.

    • Au vu de tes commentaires j’ai ajouté le motclé “compatible 3.2” à l’article mais pourrais tu aussi mettre à jour paquet.xml ?

    • Ok Goony,

      c’est une très bonne nouvelle de savoir qu’il y a du nouveau en préparation.

      Ok, pour le calcul/recalcul : donc je dois cocher “pour tout le monde” pour avoir le fonctionnement par défaut.

      .- Pour mon autre question, qui n’était pas très claire:
      un recalcul de page invalide-t-il les autres pages ? Juste un recalcul ne devrait-il pas suffire à la page.

      Mais sans être développeur, on peut vouloir par exemple modifier le squelette article.html.
      Dans ce cas, je dois vider le cache car tous les articles sont affectés.
      Mais il manque en Spip un bouton rafraîchir le cache (en push, en background) .

      C’est une fonctionnalité qui pourrait permettre de sélectionner pour un rafraichissement les articles ou d’autres objets,
      ou une liste d’Urls prioritaires par exemple .

      Merci beaucoup pour ces conseils, je vais voir si je comprends un peu le code.

      Gdf

    • Il n’y a pas de rafraichissement par squelette. Si tu fais une modification significative mais ne veux pas purger tout le cache d’un seul coup, tu peux creer une regle d’invalidation de type pull. Dans refresher_options.php tu ajoutes le code suivant:

      $GLOBALS[’refresher_objets’] = array(
      array(’squelette_article’,’article’)
      );

      Note: cet example est si le squelette principal de ta page d’article est “squelette_article.html”

      Enfin si tu veux rafraichir toutes tes pages d’article d’un seul coup, il te suffit de lancer cette requete SQL:

      delete from refresher_urls where squelette=’squelette_article’

      Et ca invalidera toutes les pages souhaitees. Je vais reflechir a un systeme pour effectuer ce genre de manipulation de maniere simple depuis la page de configuration du plugin.

    • @Jluc: honnetement je m’arrache les cheveux a chaque fois que j’essaie d’utiliser la SVN. Pour cette raison j’ai plusieurs plugins sympas que je n’ai jamais poste dans la contrib. Si une fois le nouveau plugin refresher pret, j’arrive a saisir une fois pour toute comment uploader le code, je ferai les autres dans la foulee et je mettrai a jour le paquet de celui-ci. En attendant, je n’ai meme pas envie de me lancer dans cette mission.

      EDIT: je peux tout de meme mettre a jour le zip lie a cette contrib. Je ferai cela tout a l’heure.

    • Ah ?? Je suis surpris.
      Note que maintenant, ce n’est plus SVN, mais git qui est utilisé. Les commandes sont légèrement différentes. Tu trouveras de la doc sur le net et une FAQ spécifique pour git.spip.net ici : FAQ pratique : Comment SPIPer avec git.spip.net

      Mais surtout, si tu rencontres des difficultés, demande de l’aide ! Demande sur la liste mail spip-dev ou demande sur irc #spip sur freenode. Ce serait trop bête que de petites difficultés avec git freinent ta communication de code avec les spipeurs.

    • Je connais git. Mais jusqu’ici j’utilisais tortoise SVN et tout ca. Je ne comprenais rien a ce que je faisais.

    • Bonjour Goony,

      J’ai fait quelques essais en ciblant les articles en pull
      en mettant donc dans refresher_options.php:

        $GLOBALS['refresher_objets'] = array(
              array('article', 'article')
        );

      J’ai vu que la table refresher_urls restait vide avec des urls arborescentes
      Par contre avec des ?article&id_article=55 puis ?article&id_article=68
      Il y a un remplissage partiel:

      refresher_urls

      id  uri      squelette id_objet objet
        1          article            multi_kw
        2          article            multi_kw 

      uri est dans refresher_options.php une variable $url_sv qui ne me semble pas renseignee dans mon cas d’utilisation .

      id_objet est ignore parce qu’un tiret manque ?

      if(isset($_GET['id'.$item[1]])) $id_objet = $_GET['id_'.$item[1]];

      Mais, je ne suis pas sur de mes tests.

      Donc, mon usage des urls propres n’est sans doute pas compatible avec le plugin actuel, au moins en mode pull.

      Je vais regarder du cote push, comme je cherche une recreation du cache independante des hits .

      Gdf

    • Cette version du plugin n’a ete testee qu’avec notre type d’URL et je n’avais meme pas pense a tester plusieurs types. Je suis en train de bosser la dessus en ce moment meme. Mais je peux deja te dire que les URLs bases sur des variables d’URL (du genre ?id_article=XXX) ne seront pas compatibles avec le plugin.

      Honetement je pense que tu ne devrais pas trop te creuser la tete sur cette version. Celle que je suis sur le point de partager sera bien plus simple et intuitive.

    • OK Goony,

      Oui, je comprends bien. Mettre au point un nouveau plugin et
      faire la documentation demande un gros travail.

      Comme mon cas d’utilisation concerne plus
      le raffraichissement (sans hit) des squelettes modifiés (développement) , je
      compte quand je peux dégager un peu de temps, regarder le push, pour me faire un script maison traitant en curl les articles concernés .

      Mais dans un deuxieme temps, j’aurai sans doute besoin du (nouveau?) plugin, pour les cas d’édition.

      Gdf

    • Le rafraichissement par squelette est une nouvelle fonctionalite que j’ai integre recemment suite a ta suggestion, et c’est tres facile a appliquer dans le contexte du plugin. Tu pourras invalider les caches (pull) ou meme rafraichir toutes les pages en tache de fond (push) qui utiliseent un certain squelette (selection par squelette principal uniquement). J’ai encore quelques fonctions a tester puis le plugin sera probablement poste dans 15j environ.

    Reply to this message

  • 3

    Bonjour,
    Est ce que ce plugin est compatible avec Varnish ? et Memoization ?
    Merci

    • nous n’utilisons pas ces plugins, donc a vous de voir et de nous dire ;)

      Mais avec ce plugin refresher vous ne devriez plus avoir besoin de memoization ou varnish. l’idee etant de creer des pages statiques, en file d’attente avant leur consultation.

      Donc la vitesse a laquelle les pages sont cree n’est plus tres importante, a part pour ce qui est de la vitesse de mise a jour du site,

      L’idee est de ne plus avoir a se soucier de charge server ou de temps d’execution. tout se passe en file d’attente, avec un test de le charge du server pour ralentir la file si necessaire.

    • Voila ce que je peux dire (spip 311, pas de CDN) :
      -  Varnish + Memoization = google page speed 95/100 avec erreur d’injection SQL dans la partie privée
      -  Varnish seul = 100/100
      -  Varnish + Refresher = 100/100, plus d’erreur SQL
      je vais tester plus longtemps ...

    • Bonjour,

      Je ne suis pas sur que ces tests soient revelateurs de quoi que ce soit. Les plugins Varnish et Memoization semblent mettre en cache des informations supplementaires afin d’augmenter la vitesse de SPIP.

      Ce que le plugin Refresher fait, est qu’on n’invalide plus la totalite du site en cas d’action editoriale. Donc il n’y a pas vraiment de benchmark possible, si ce n’est constater que le serveur passe moins de temps a construire des pages. Les visiteurs et les bots auront l’impression que le site sera plus rapide non pas parcequ’on a booste SPIP, mais parcequ’ils tomberont toujours sur des pages deja en cache.

      Donc comme on agit a un autre niveau, je pense que notre plugin est compatible avec les autres plugins de cache et n’interfere pas. En revanche, il peut rendre d’autres plugins inutiles. Par exemple le plugin Cache-cool n’aurait plus vraiment d’interet. Avec le Refresher, on peut mettre un temps de vie maximum (potentiellement infini) a nos squelettes. Les rafraichissements sont forces, mais effectues uniquement quand ils sont necessaires. Le rafraichissement “par vieillissement” que le Cache-cool optimise n’est plus utilise par le site.

    Reply to this message

Ajouter un commentaire

Who are you?
[Log in]

To show your avatar with your message, register it first on gravatar.com (free et painless) and don’t forget to indicate your Email addresse here.

Enter your comment here

This form accepts SPIP shortcuts {{bold}} {italic} -*list [text->url] <quote> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Add a document

Follow the comments: RSS 2.0 | Atom