Cache d'un inclure à répétition avec var_mode

Dev
1

Bonjour,

avec var_mode dans l’url,
si j’inclus plusieurs fois le même squelette avec les mêmes paramètres,
j’ai l’impression que le cache de ce squelette est recréé à chaque inclusion.

Est-ce voulu ou est-ce un bug ? car logiquement, le renouvellement du cache de ce squelette ne devrait être fait qu’a la première inclusion, les autres inclusions utilisant le cache nouvellement créé.

apparemment ça se passe la :

2

Salut,

Avec uniquement var_mode dans l’url ?

Quel est le code de l’inclure en question ?

++

3

oui le problème se pose uniquement quand var_mode est dans l’url, le seul autre argument dans l’url étant le nom de la page.

j’ai pris comme exemple un inclure tout simple sur un site de test pour mettre en évidence le problème que j’ai déjà rencontré ailleurs.

<BOUCLE_article(ARTICLES){id_article=1}>
<h3>#TITRE</h3>
</BOUCLE_article>

Il n’y a qu’a faire le test, appeler une page toute simple qui inclus plusieurs fois le squelette ci-dessus.

Avec var_mode dans l’url, plus je mets d’inclusions dans la page, plus le chargement de la page sera long. L’explication est donnée si on ajoute var_profile=1 dans l’url en plus de var_mode : la requête générée par la boucle du squelette inclus apparaît dans le compte rendu de var_profile aussi autant de fois qu’il y a d’inclusions.

je précise que le problème est présent autant dans spip 3.2 que spip 4.0

4

Ha mais quand je demandais le code de l’inclure, c’est surtout la manière dont tu fais l’inclusion :stuck_out_tongue:

5

Oui c’est normal, ou en tout cas c’est la spec depuis toujours : avec un var_mode=calcul on ignore tous les caches : donc à chaque inclusion on fait le calcul quelle que soit l’ancienneté du cache, y compris si elle vient d’être calculée dans le même hit.

On pourrait certes faire mieux mais

  • ça suppose du code en plus et de la complexité en plus, et donc des bugs en plus
  • pour un gain a priori marginal compte tenu du fait qu’il est quand même assez rare d’afficher N fois la même chose dans une page (ie le produit d’une même inclusion avec les mêmes paramètres)
  • et que tout ça n’impacte pas la vie courante du site mais uniquement les admins qui forcent des mises à jours (via le bouton « voir en ligne » parfois, certes)
6

ah ok pardon j’avais pas compris comme ça

en fait l’appel se fait juste en dynamique, sans paramètres :
<INCLURE{fond=monsquelette}>

Le problème se produit aussi en statique avec [(#INCLURE{fond=monsquelette})]

ok, je comprends.

A noter cependant que ce problème se retrouve aussi dans l’utilisation de var_profile quand on veut l’associer à var_mode. En fait, ça vient même polluer le résultat de var_profile.

Cela dit, une solution en apparence toute simple, mais peut-être une subtilité m’échappe t-elle, ne serait-elle pas de garder en mémoire les chemin caches déjà traités dans le hit ?

Car si je comprends bien un chemin cache est propre à un squelette et son contexte,
donc ne suffirait-il pas de renouveler le cache du squelette que si le chemin n’est pas encore enregistré comme ayant été traité ?

j’ai fait un petit essai sur un site de test (surcharge de public_cacher_dist) et ça à l’air de fonctionner.