donc si chaque nouvel article syndiqué invalide tout le cache, c'est
AMHA pénalisant pour le visiteur.
En fait les nouveaux articles syndiqués n'invalident pas les caches.
Une idée pourrait être d'avoir un critère de #CACHE{} qui dise "ne pas
se formaliser de l'invalidation par date_dernier_modif", ça a été
proposé il y a qqs jours sur la liste je crois. As usual, send some
code.
-- Fil
donc si chaque nouvel article syndiqué invalide tout le cache, c'est
AMHA pénalisant pour le visiteur.En fait les nouveaux articles syndiqués n'invalident pas les caches.
Ah, je ne savais pas. Comment se met à jour le cache de Sedna, alors ?
Une idée pourrait être d'avoir un critère de #CACHE{} qui dise "ne pas
se formaliser de l'invalidation par date_dernier_modif", ça a été
proposé il y a qqs jours sur la liste je crois.
Pourquoi ne pas tout simplement prendre en compte les delai présents dans les squelettes existants ?
Comme ça la syntaxe ne change pas, et les gens qui upgradent n'ont pas de modification du fonctionnement de leur site tant qu'ils ne retirent pas volontairement ces instructions de leurs squelettes.
As usual, send some code.
Faudrait déjà que j'arrive à refaire fonctionner un SPIP, cf mes autres messages du jour...
-Nicolas
Fil a écrit :
donc si chaque nouvel article syndiqué invalide tout le cache, c'est
AMHA pénalisant pour le visiteur.En fait les nouveaux articles syndiqués n'invalident pas les caches.
Une idée pourrait être d'avoir un critère de #CACHE{} qui dise "ne pas
se formaliser de l'invalidation par date_dernier_modif", ça a été
proposé il y a qqs jours sur la liste je crois. As usual, send some
code.-- Fil
L'idée pourrait être de générer un cache par page et de ne pas recalculer ce cache tout le temps. Se contenter de le régénérer si la page change (commentaire ou modif de l'utilisateur).
Ceci permet de ne pas recalculer tout le cache d'un site lorsque quelqu'un poste un commentaire sur un article.
Sur un petit site le calcul ne doit pas être énorme mais lorsqu'il y'a bcp d'articles la charge machine associés est bcp plus élevé et de fait l'expérience utilisateur s'en trouve dégradée. (Et au passage les nerfs du sysadmin en prennent un coup aussi).
Rien n'empêche en complément de programmer une purge régulière de tout le cache toutes les 24H par exemple.
Reste après le problème de ceux qui souhaitent avoir des citations aléatoires qui changent à chaque clic, mais dans ce cas là il vaudrait mieux ne pas avoir de cache du tout sur la page.
Concernant les flux rss je présume qu'il y'a un cache local déjà, du moment que ce cache a une durée de vie convenable (4H peut être), cela ne devrait pas invalider trop souvent le cache général du site.
Bon après il y'a l'utilisateur final qui s'amuse à donner une durée de vie de 10 min à son cache, mais là on peux pas y faire grand chose... Si ce n'est peut être lui expliquer qu'un cache de 24H est suffisant pour quelqu'un qui écrit un article par mois... Mais c'est un autre débat.
sich
sich a écrit :
Fil a écrit :
donc si chaque nouvel article syndiqué invalide tout le cache, c'est
AMHA pénalisant pour le visiteur.
En fait les nouveaux articles syndiqués n'invalident pas les caches.
Une idée pourrait être d'avoir un critère de #CACHE{} qui dise "ne pas
se formaliser de l'invalidation par date_dernier_modif", ça a été
proposé il y a qqs jours sur la liste je crois. As usual, send some
code.-- Fil
L'idée pourrait être de générer un cache par page et de ne pas recalculer ce cache tout le temps. Se contenter de le régénérer si la page change (commentaire ou modif de l'utilisateur).
encore une fois, on ne parle pas de "page" mais de "cache".
ma page article peut contenir des caches liés à son secteur, à sa rubrique, à un mot clé... ces caches n'ont pas à etre recalculé si le descriptif de la rubrique change.
C'est l'ancien systeme et il me semble qu'on peut le réactiver en SVN.
Ceci permet de ne pas recalculer tout le cache d'un site lorsque quelqu'un poste un commentaire sur un article.Sur un petit site le calcul ne doit pas être énorme mais lorsqu'il y'a bcp d'articles la charge machine associés est bcp plus élevé et de fait l'expérience utilisateur s'en trouve dégradée. (Et au passage les nerfs du sysadmin en prennent un coup aussi).
tout depend de la requete (et donc de la boucle)
si je fais <BOUCLE_A(ARTICLES){id_article}> sur 30000 article ou sur 100 articles, la difference est négligeable.
par contre <BOUCLE_A(ARTICLES){titre_mot==^toto}>, ca fait tout de suite plus mal.
La "taille" du site ne va pas impacter tous les squelettes de la meme facon.
Rien n'empêche en complément de programmer une purge régulière de tout le cache toutes les 24H par exemple.
c'est amha une tres mauvaise approche, ca prend tous les inconvenants de l'invalidation globale (le premier qui passe après l'invalidation se mange tous les recalcul) sans les avantages (cache synchro).
le principal reproche fait à l'ancien systeme etait : soit on gere des invalideurs, soit on gere une expiration.
le savant melange des 2, c'etait plutot à cause de limitations (volontaires pour ne pas plomber la gestion du cache) dans la gestion des invalideurs.
mais l'avantage du delai par squelette, c'est que statistiquement, on ne se tape pas tous les recalcul, mais seulement une partie.
Reste après le problème de ceux qui souhaitent avoir des citations aléatoires qui changent à chaque clic, mais dans ce cas là il vaudrait mieux ne pas avoir de cache du tout sur la page.
#CACHE{0}
Concernant les flux rss je présume qu'il y'a un cache local déjà, du moment que ce cache a une durée de vie convenable (4H peut être), cela ne devrait pas invalider trop souvent le cache général du site.
Dans Spip en general, l'invalidation n'intervient pas au calcul de la page mais lors des modifs en base.
Bon après il y'a l'utilisateur final qui s'amuse à donner une durée de vie de 10 min à son cache, mais là on peux pas y faire grand chose... Si ce n'est peut être lui expliquer qu'un cache de 24H est suffisant pour quelqu'un qui écrit un article par mois... Mais c'est un autre débat.
mais si quelqu'un n'ecrit qu'un article par mois, pourquoi recalculer inutilement la page tous les jours ?
autant avoir un cache qui n'expire jamais mais est recalculé en cas de changement (ici 30 fois moins de recalcul...)
Pour un hebergeur et à l'echelle de dixaines ou centaines de sites, le nouveau systeme est sans doute le plus efficace.
C'est quand on commence à faire des choses complexes et à travailler avec des caches perso / par statut... qu'on a besoin d'autre chose : une gestion souple de l'invalidation et donc l'exclusion de ces squelettes de l'expiration globale.
C'est sans doute la meilleure piste, mais il faut la coder...
@++
Stephane a écrit :
...
Merci pour toutes ces précisions.
sich
cedric.morin@yterium.com a écrit :
Nicolas Hoizey a écrit :
Sauf que là tu oublies les sites à faible trafic bougeant beaucoup, pour lesquels toute page visitée risque d'être recalculée, avec du coup un cache inutile...
Si le traffic est faible, les pages etaient deja recalculées à chaque fois. Et tu épargne toute l'usine à gaz des invalideurs.
Un peu d'IA serait peut être possible alors ?
Puisque spip dispose
1) des stats de visite,
2) de la possibilité de connaitre les temps divers de calcul
spip pourrait sur option
aiguiller les pages à faible traffic
(relativement à durée du cache et/ou calcul requis)
vers cache ou pas cache ou autre type de cache...
JLuc
sich a écrit :
Si j'ai bien suivis sur spip le cache est invalidé dès qu'il y'a une modif ou qu'il expire (logique).
mouil me semble aussi
mais on pourrait faire appel à l'IW ici (intelligence webmaster)
cela pourrait être paramétrable par le créateur de squelette,
page par page, avec genre un param supplémentaire de #cache
pour dire "independant" (=stable) ou "dépendant" (=recalculé souvent).
(pour n'utiliser qu'un booléen, mais ce pourrait être un graphe)
Et dans utospip, il pourrait y avoir une passe supplémentaire
du compilateur (comme lors du link des .obj),
pour le compilateur lui même repère les squelettes stables
et les instables...
re
JL
Et concrètement ?
on peut voir les url comparées d'un site en spip/joomla/phpbb sur ta machine ?
J'ai compris que tu n'avais pas de bench, et que l'on était pour le moment dans une discussion de café, mais si tu décrivais un peu ton problème, ou que tu donnais de la matière on pourrait avancer.
Moi j'en suis resté sur ton affirmation que la page d'un site en spip mettait plusieurs secondes à arriver alors que celle d'un joomla ou d'un phpbb etait presque instantanée, tout cela sur le meme serveur. Je n'ai pas la chance d'avoir des sites en joomla ou en phpbb sur mon serveur d'hebergement, je ne peux donc pas faire de comparaison, mais si tu fournis deja 3 urls des 3 systèmes hebergés sur une meme machine, on pourrait commencer à bencher et comprendre les différences.
Merci
Cédric
C'est pas les idées qui manquent, ni les propositions ; la preuve, il suffit de demander sur la liste pour que chacun propose la façon dont il pense que cache devrait marcher.
Mais en la matière, il n'y a que les cas concrets et les situations de stress réelles qui permettent d'avancer.
Et la il y a beaucoup moins de monde 
Cédric