Refresher - commentaires

Refresher

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

Refresher

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.

Refresher

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

Refresher

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.

Refresher

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

Refresher

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

Refresher

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.

Refresher

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

Refresher

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.

Refresher

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

Refresher

Au vu de tes commentaires j'ai ajouté le motclé « compatible 3.2 » à l'article mais pourrais tu aussi mettre à jour paquet.xml ?

Refresher

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

Refresher

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.

Refresher

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

Refresher

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

Refresher

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.

Refresher

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

Refresher

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.

Refresher

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

Refresher

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

Refresher

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

Refresher

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.

Refresher

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

Refresher

je voulais poster un petit message de mise a jour.

nous utilisons cette contributions maintenant depuis presque 2 ans et nous en somme tres content.

nous servons +- 300,000 pages vue par jour avec une charge server tres faible.

nous 'push'ons desormais nos fichiers cache vers 'google cloud storage' (simple et pas cher) et nous indiquons a notre CDN d'aller chercher les fichiers en deux temps, en premier sur le cloud storage et si non disponible (trop recent) sur le server live.

Ce system isole completement le server du traffic web. Nous avons eu des piques de traffic enorme sans aucune charge de server supplementaire.

Seul point ennuyeux, le nombre de taches de fonds pour rafraichir le contenu editorial ralenti parfois les mises a jours de certaines pages. Par exemple un article avec beaucoup de mot cles, beaucoups de documents, prend un certain temp a apparaitres sur toutes pages les mots cles.

Mais au final je pense que le leger delai est moins important que le fait d'etre sur que le site n'ai pas de soucis en cas de pique de traffic et de robots aspirateurs recalcitrant.

Je suis surpris de ne pas voir de message sur cette contrib. J'espere que d'autres sites a fort traffic s'y interesseront. Nous serions heureux de voir cette contrib utilise et ameliore par d'autres sites.