Questions sur conception de squelette

Fredo_Mkb · Mai 28, 2007, 11:57

Bonjour à tous

Voilà, je penche depuis un moment sur la prochaine évolution du squelette MiniGriSpip (voir <http://fredomkb.free.fr/spip/>).

Dès le départ de ce projet, j'ai souhaité faire quelque chose de facilement compréhensible et accessible aux débutants, puisque je l'étais moi-même alors (et je le reste largement encore aujourd'hui).

Or, les évolutions que je souhaite intégrer au squelette impliquent, fatalement, une plus grande complexité du code, et j'ai peur, dans cet élan, d'en faire un peu trop, c'est pourquoi je me pose un certain nombre de questions, que je souhaite vous soumettre, pour avoir votre avis et ne pas risquer de continuer sur une mauvaise voie...

----------

La première question concerne l'utilisation de JavaScript.

Je souhaite proposer quelques améliorations ergonomiques au squelette, mais elles ne sont uniquement possibles que par l'utilisation de JavaScript.

Alors, sachant que je compte faire en sorte que le squelette reste fonctionnel même si JavaScript est désactivé chez l'utilisateur, ou si son navigateur ne supporte pas ce langage, à votre avis :

Pensez-vous que c'est une bonne chose ou il faut éviter l'utilisation de JavaScript ?

Quels problèmes ça peut éventuellement poser l'utilisation de ce langage ?

Selon vous, quelles sont les précautions à prendre ?

----------

Une autre question qui fait travailler mes neurones chauffés à blanc, c'est l'utilisation des "<INCLURE>".

Alors, dans les nouvelles fonctionnalités que je souhaite intégrer, il y a un certain nombre qui nécessitent l'inclusion des petites noisettes récurrentes, qui seraient très fastidieuses à maintenir si je les intègre directement dans les code des pages, donc, vive les "<INCLURE>" !

Seulement, un bon nombre de ces noisettes réclament pas mal de variables, qui conditionnent leur utilisation selon le contexte dans lequel ils seront intégrés.

Or, il me semble avoir lu justement qu'il fallait limiter l'utilisation des "<INCLURE>", surtout s'il y a beaucoup de variables à passer, pour des simples raisons de performances dans l'analyse et la fabrication des pages par Spip.

Qu'en est-il au juste ?

Vaut-il mieux multiplier des petites noisettes spécifiques, qui ne réclament pas beaucoup de variables, à la place de noisettes plus génériques mais nécessitant un plus grand nombre de variables ?

Aurait-il une limite connue à propos du nombre de variables à passer aux "<INCLURE>" ?

Aurait-il d'autres solutions alternatives pour conserver une bonne modularité du squelette, avec des noisettes généralistes, tout en garantissant des bonnes performances ?

Bref, quel est votre avis sur l'utilisation généralisée des "<INCLURE>" avec plusieurs variables ?

Par ailleurs, il existe désormais une balise "#INCLURE", présentée dans la page de Spip 1.9.1 (voir <http://www.spip.net/fr_article3462.html>).

Son fonctionnement semble légèrement différent de l'autre syntaxe habituelle, mais je n'ai pas bien saisi dans quelles conditions faut-il privilégier l'une par rapport à l'autre, auriez-vous quelques précisions et/ou exemples à ce propos ?

----------

Enfin, voici une dernière question qui me taraude...

Dans la même page de présentation de la version 1.9.1 de Spip, on trouve également la technique d'utilisation des "fragments", sous le titre "Rechargement partiel de page (expérimental)" (voir <http://www.spip.net/fr_article3462.html>).

Que pensez-vous de cette technique qui permet de charger une portion de squelette sans avoir à recharger l'ensemble de la page ?

Comme il s'agit d'une solution expérimentale pour l'instant, quel avenir peut-on espérer pour cette technique ?

Dans ces conditions, est-il judicieux de s'en servir dans un squelette voué à être distribué à d'autres utilisateurs ?

Pour la petite histoire, j'ai fais des petits tests il y a quelques semaines, et la technique semble très bien fonctionner... en espèrant qu'elle ne sera pas obsolète sur les prochaines versions de Spip.

----------

Voilà, en gros, mes interrogations existentielles actuelles (j'en ai d'autres, mais c'est déjà bien suffisant pour cette fois ;-)), n'hésitez pas à me faire part de votre opinion et expérience, en espératn qu'il aura, parmi les spécialistes de la liste, certains qui sauront m'apporter quelques réponses et/ou éclaircissements ...

Merci à tous... à+
--
Fredo d;o)
"Un pas à la fois me suffit..." (Gandhi)

6ce29918f2b7cfb60ff3 · Mai 29, 2007, 5:43

Fredo Mkb wrote:

Bonjour à tous

Voilà, je penche depuis un moment sur la prochaine évolution du
squelette MiniGriSpip (voir <http://fredomkb.free.fr/spip/>\).

Dès le départ de ce projet, j'ai souhaité faire quelque chose de
facilement compréhensible et accessible aux débutants, puisque je
l'étais moi-même alors (et je le reste largement encore aujourd'hui).

Or, les évolutions que je souhaite intégrer au squelette impliquent,
fatalement, une plus grande complexité du code, et j'ai peur, dans cet
élan, d'en faire un peu trop, c'est pourquoi je me pose un certain
nombre de questions, que je souhaite vous soumettre, pour avoir votre
avis et ne pas risquer de continuer sur une mauvaise voie...

----------

La première question concerne l'utilisation de JavaScript.

Je souhaite proposer quelques améliorations ergonomiques au squelette,
mais elles ne sont uniquement possibles que par l'utilisation de
JavaScript.

Alors, sachant que je compte faire en sorte que le squelette reste
fonctionnel même si JavaScript est désactivé chez l'utilisateur, ou si
son navigateur ne supporte pas ce langage, à votre avis :

Pensez-vous que c'est une bonne chose ou il faut éviter l'utilisation
de JavaScript ?

Quels problèmes ça peut éventuellement poser l'utilisation de ce
langage ?

Selon vous, quelles sont les précautions à prendre ?

----------

Une autre question qui fait travailler mes neurones chauffés à blanc,
c'est l'utilisation des "<INCLURE>".

Alors, dans les nouvelles fonctionnalités que je souhaite intégrer, il
y a un certain nombre qui nécessitent l'inclusion des petites
noisettes récurrentes, qui seraient très fastidieuses à maintenir si
je les intègre directement dans les code des pages, donc, vive les
"<INCLURE>" !

Seulement, un bon nombre de ces noisettes réclament pas mal de
variables, qui conditionnent leur utilisation selon le contexte dans
lequel ils seront intégrés.

Or, il me semble avoir lu justement qu'il fallait limiter
l'utilisation des "<INCLURE>", surtout s'il y a beaucoup de variables
à passer, pour des simples raisons de performances dans l'analyse et
la fabrication des pages par Spip.

Qu'en est-il au juste ?

Vaut-il mieux multiplier des petites noisettes spécifiques, qui ne
réclament pas beaucoup de variables, à la place de noisettes plus
génériques mais nécessitant un plus grand nombre de variables ?

Aurait-il une limite connue à propos du nombre de variables à passer
aux "<INCLURE>" ?

Aurait-il d'autres solutions alternatives pour conserver une bonne
modularité du squelette, avec des noisettes généralistes, tout en
garantissant des bonnes performances ?

Bref, quel est votre avis sur l'utilisation généralisée des
"<INCLURE>" avec plusieurs variables ?

Par ailleurs, il existe désormais une balise "#INCLURE", présentée
dans la page de Spip 1.9.1 (voir
<http://www.spip.net/fr_article3462.html>\).

Son fonctionnement semble légèrement différent de l'autre syntaxe
habituelle, mais je n'ai pas bien saisi dans quelles conditions
faut-il privilégier l'une par rapport à l'autre, auriez-vous quelques
précisions et/ou exemples à ce propos ?

Une partie de réponse:

Lorsque tu utilises une balise "#INCLURE" ou #MODELE, dans les faits,
une fois calculé, le code est écrit directement dans le squelette qui contient
cette balise alors que si tu fais un <INCLURE..., c'est du code php qui est écrit dans ton squelette
Du style:

<?php
$contexte_inclus = array('fond' => 'modeles/mod_inc',
'lang' => 'fr');
include(_DIR_RESTREINT . "public.php");
?>

Les balises "#INCLURE" ou #MODELE sont dites static.
C'est à dire "en gros" qu'elles ne seront pas recalculées si la page n'est pas recalculée.

Mais là ou ça peut faire mal, c'est le temps requi pour les calculer et les inclures à chaque appel de ton squelette.

Même si ta page est en cache, un INCLURE dynamique doit être appellé, vérifié s'il est périmé ou non, recalculé au besoin.
Alors qu'en static, le résultat est dans la page en cache. Donc pas d'appel et tous le reste.

J'ai fais une petite page pour tester le tout.
Le test appel le même fichier des trois façons.
Résultat moyen:
#INCLURE et #MODELE donne en moyenne 0.0001 seconde
<INCLURE... demande en moyenne 100 fois plus de temps soit 0.01

La différence entre un <INCLURE... qui utilise le cache et un qui ne l'utilise pas,
la différence est négligeable. Donc, c'est l'appel et la vérification de la vie de l'INCLURE qui demande du temps.

Je vais détailler mon test bientôt mais si tu veux voir le résultat:
http://monsitespip.com/spip.php?page=test_mod_inc_1&nbr=1

Dans le fichier appellé, une simple boucle:
<BOUCLE_article(ARTICLES){0,10}>
#ID_ARTICLE-
</BOUCLE_article>

Si tu fais un squelette qui comporterait disons 10 inclusions:
si tu n'as pas besoin du INCLURE dynamique, tu aurais donc un squelette que se calculerait
près de 1000 fois plus vite...

À moins que je n'ai raté quelque chose, c'est pour le moins ce que me dit mon test...

François

----------

Enfin, voici une dernière question qui me taraude...

Dans la même page de présentation de la version 1.9.1 de Spip, on
trouve également la technique d'utilisation des "fragments", sous le
titre "Rechargement partiel de page (expérimental)" (voir
<http://www.spip.net/fr_article3462.html>\).

Que pensez-vous de cette technique qui permet de charger une portion
de squelette sans avoir à recharger l'ensemble de la page ?

Comme il s'agit d'une solution expérimentale pour l'instant, quel
avenir peut-on espérer pour cette technique ?

Dans ces conditions, est-il judicieux de s'en servir dans un squelette
voué à être distribué à d'autres utilisateurs ?

Pour la petite histoire, j'ai fais des petits tests il y a quelques
semaines, et la technique semble très bien fonctionner... en espèrant
qu'elle ne sera pas obsolète sur les prochaines versions de Spip.

----------

Voilà, en gros, mes interrogations existentielles actuelles (j'en ai
d'autres, mais c'est déjà bien suffisant pour cette fois ;-)),
n'hésitez pas à me faire part de votre opinion et expérience, en
espératn qu'il aura, parmi les spécialistes de la liste, certains qui
sauront m'apporter quelques réponses et/ou éclaircissements ...

Merci à tous... à+

Paolo · Mai 29, 2007, 6:17

François Vachon wrote:

Lorsque tu utilises une balise "#INCLURE" ou #MODELE, dans les faits,
une fois calculé, le code est écrit directement dans le squelette qui contient cette balise alors que si tu fais un <INCLURE..., c'est du

> code php qui est écrit dans ton squelette

(...)

François,

Je trouve ce que tu as écrit là très utile !

Ne pourrais-tu pas le publier comme article sur spip-contrib, par exemple dans cette rubrique :
SPIP-Contrib ?

Je n'ai pas vu la différence si bien expliqué avant.

Moi-même, je vais voir si je peux supprimer des <INCLURE> ...

> si tu n'as pas besoin du INCLURE dynamique, tu aurais donc un
> squelette que se calculerait près de 1000 fois plus vite...

Alors quelles peuvent être les situations où en a besoin du INCLURE dynamique ?

Paolo

RealET · Mai 29, 2007, 7:02

* Paolo tapotait, le 29/05/2007 20:17:

Alors quelles peuvent être les situations où en a besoin du INCLURE dynamique ?

Exemple : afficher une citation aléatoire toute les heures alors que le squelette incluant a un cache de 30 jours.

--
RealET

J-C · Mai 29, 2007, 7:59

RealET a écrit :

* Paolo tapotait, le 29/05/2007 20:17:

Alors quelles peuvent être les situations où en a besoin du INCLURE 
dynamique ?

Exemple : afficher une citation aléatoire toute les heures alors que le 
squelette incluant a un cache de 30 jours.

Citation …Non pas de troll, svp !

d979d7e88876a434c7e2 · Mai 29, 2007, 8:07

RealET a écrit :

* Paolo tapotait, le 29/05/2007 20:17:

Alors quelles peuvent être les situations où en a besoin du INCLURE dynamique ?

Exemple : afficher une citation aléatoire toute les heures alors que le squelette incluant a un cache de 30 jours.

D'une manière générale quand le contexte de l'inclusion et different de celui de l'incluant et que les morceaux de cache générés peuvent etre partagés.

Ca aura du sens pour une "noisette" de mot ou de groupe de mot ou de rubrique dans un squelette article par exemple.
Mais c'est quand meme plutot pour les calculs compliqués car multiplier les fichiers de cache degrade en contre partie un peu les perfs (enfin, ca depend des plateformes et de leur utilisation, mais les acces disque sont couteux).

Autre cas "classique", c'est l'inclusion d'un script personnel avec <INCLURE(xxx.php){xxx=#TOTO}> (que j'utilise pour faire des caches perso ou par statut)

Si c'est juste une question de maintenabilité, ou si on veut une info synchrone, autant utiliser #INCLURE.

mes 2 sous.
@++

Eric_L · Mai 29, 2007, 8:38

Paolo a écrit :

Alors quelles peuvent être les situations où en a besoin du INCLURE dynamique ?

Partout où tu as besoin d'un cache particulier pour ton inclure (genre #CACHE{0} par ex)

Eric

Paolo · Mai 29, 2007, 10:58

spipcarto wrote:

D'une manière générale quand le contexte de l'inclusion et different de celui de l'incluant et que les morceaux de cache générés peuvent etre partagés.

Ca aura du sens pour une "noisette" de mot ou de groupe de mot ou de rubrique dans un squelette article par exemple.
Mais c'est quand meme plutot pour les calculs compliqués car multiplier les fichiers de cache degrade en contre partie un peu les perfs (enfin, ca depend des plateformes et de leur utilisation, mais les acces disque sont couteux).

Hmm. Tu permets que je prend un exemple concret (une page de notre site évidemment !)

Alors http://www.taize.fr/fr_article3668.html est produit par le squelette
http://www.taize.fr/squelettes/artnorm.html
qui contient <INCLURE> 5 fois.

1. Il y a le sélecteur de langue, inséré avec
<INCLURE{fond=ti_langselect}{id_article}{lang}>
je me dis que cela devrait être fait avec une inclusion "statique". L'HTML produit ne va pas être le même pour une autre page.

2. La case "Rechercher", inséré avec
<INCLURE{fond=ti_searchbox}{lang}>
alors d'un côté, l'HTML est partageable avec toutes les autres pages de cette langue, donc il vaut mieux un <INCLURE>,
mais de l'autre côté, il vaut peut-être mieux calculé la petite quantité d'HTML et la garder dans le squelette comme François expliquait - ce qui est un argument pour une inclusion statique. Alors quel avantage pèse le plus ici ?

3. Le menu horizontal avec les "chapitres" du site, inséré avec
<INCLURE{fond=ti_hmenu}{id_rubrique}>
Je me dis qu'il est très rare que nous ajoutons/changeons ces chapitres, alors je pourrais remplacer cet <INCLURE> par une inclusion statique.

4. Le menu de gauche: compliqué et coûteux à calculer, inséré avec
<INCLURE{fond=ti_vmenu}{id_article}{id_rubrique}{id_mot}{lang}>
qui a son tour comporte une autre inclusion (inc-vmenu).
Puis-je faire un inclusion statique pour ça ?
En ce moment je fais tourner le menu (ti_vmenu) avec un cache de 7200 tandis que le squelette de l'article a un cache de 86400.
Mais peut-être ce serait mieux de réduire le cache de l'article et inclure le menu en statique ?

5. le pied de l'article
<INCLURE{fond=ti_footer}{lang}>
c'est le même cas exactement que no.2
il y a une bonne raison pour faire <INCLURE> une autre pour en faire une inclusion statique.

Je ne veux pas, en ayant écrit tout cela, vous contraindre à étudier mes squelettes. Ce sont en tout cas les questions que je me pose après avoir lu ce fil de discussion.

Paolo

stanislas76 · Mai 30, 2007, 2:33

Eric Lurand <elurand <at> free.fr> writes:

Partout où tu as besoin d'un cache particulier pour ton inclure (genre

#CACHE{0} par ex)

Je me souviens d'une remarque juste de spipcarto qui prohibait la balise cache à
zéro notamment pour parer la connexion de 2 internautes à quelques secondes.
Donc a minima cache à 15s par exemple...

stanislas76 · Mai 30, 2007, 2:37

Fredo Mkb <fredomkb <at> free.fr> writes:

je me pose un certain
nombre de questions, que je souhaite vous soumettre, pour avoir votre
avis

Je me suis souvent demandé aussi si l'ordre des critères dans une boucle avait
une incidence sur la rapidité... ou si le critère {id_mot=2} était plus
performant que {titre_mot=edito}...

Stanislas

d979d7e88876a434c7e2 · Mai 30, 2007, 2:43

Paolo a écrit :

spipcarto wrote:

D'une manière générale quand le contexte de l'inclusion et different de celui de l'incluant et que les morceaux de cache générés peuvent etre partagés.

Ca aura du sens pour une "noisette" de mot ou de groupe de mot ou de rubrique dans un squelette article par exemple.
Mais c'est quand meme plutot pour les calculs compliqués car multiplier les fichiers de cache degrade en contre partie un peu les perfs (enfin, ca depend des plateformes et de leur utilisation, mais les acces disque sont couteux).

Hmm. Tu permets que je prend un exemple concret (une page de notre site évidemment !)

Alors http://www.taize.fr/fr_article3668.html est produit par le squelette
http://www.taize.fr/squelettes/artnorm.html
qui contient <INCLURE> 5 fois.

1. Il y a le sélecteur de langue, inséré avec
<INCLURE{fond=ti_langselect}{id_article}{lang}>
je me dis que cela devrait être fait avec une inclusion "statique". L'HTML produit ne va pas être le même pour une autre page.

oui puisque ca depend de id_article comme l'incluant, ca doit de toute facons etre calculé en meme temps

2. La case "Rechercher", inséré avec
<INCLURE{fond=ti_searchbox}{lang}>

j'ai pas bien compris ce squelette...
A mon avis tu n'as pas besoin de boucle la.
Sur un truc simple comme ca, amha, autant faire #INCLURE

alors d'un côté, l'HTML est partageable avec toutes les autres pages de cette langue, donc il vaut mieux un <INCLURE>,
mais de l'autre côté, il vaut peut-être mieux calculé la petite quantité d'HTML et la garder dans le squelette comme François expliquait - ce qui est un argument pour une inclusion statique. Alors quel avantage pèse le plus ici ?

si le morceau de code n'a jamais à etre recalculé (la langue du secteur ne changeant jamais), et si effectivement il y a une requete, et que l'article lui est calculé frequement, alors autant faire un inclure dynamique et mettre un delai de cache tres élevé.
Mais si ton article n'est pas calculé souvent, autant faire #INCLURE et eviter un acces disque à chaque hit.

En gros, de toutes facons, c'est un ratio nb hits / nombre de recalculs.

utiliser #INCLURE ralentira le recalcul (eventuellement beaucoup) mais < INCLURE > ralentira (un tout petit peu) l'affichage.

3. Le menu horizontal avec les "chapitres" du site, inséré avec
<INCLURE{fond=ti_hmenu}{id_rubrique}>
Je me dis qu'il est très rare que nous ajoutons/changeons ces chapitres, alors je pourrais remplacer cet <INCLURE> par une inclusion statique.

Pas si sur...
c'est typiquement le genre de squelette qui doit etre dynamique avec un temps de mise en cache enorme.
Tu ne veux pas recalculer le menu, qui fait 3 requetes requetes, à chaque recalcul d'article et rubrique

Mais comme je le disais, ca depend de l'utilisation :

Si tu as des forums actifs sur tes articles par exemple, ca pourrait devenir plus couteux d'utiliser #INCLURE.

Si les articles sont relativement statiques et tres visités, il vaut mieux utiliser #INCLURE

4. Le menu de gauche: compliqué et coûteux à calculer, inséré avec
<INCLURE{fond=ti_vmenu}{id_article}{id_rubrique}{id_mot}{lang}>
qui a son tour comporte une autre inclusion (inc-vmenu).
Puis-je faire un inclusion statique pour ça ?

oui sur le principe, puisque tu as de toutes facons un cache par article, pas la peine de le mettre dans un fichier à coté.

Peut etre pas pour les inclusions de inc-vmenu par contre, car ca peut etre interessant de conservé chaque petit bout de cache en ne le calculant qu'une fois de temps en temps.

Le probleme de mettre trop de #INCLURE, c'est qu'on se retrouve au final avec beaucoup de calcul d'un coup.
On y gagne en moyenne, mais un hit de temps à autres, c'est la cata au niveau des perfs (quand on ne bloque pas carrement en depassant le temps de calcul aloué)

Voila mes 2 sous.
@++

PS : Ceci dit, je ne suis pas sur d'avoir compris les dernieres remarques de Fil sur l'invalidation du cache... je crois que l'invalidation est assez brutale maintenant.

d979d7e88876a434c7e2 · Mai 30, 2007, 3:14

Stanislas a écrit :

Eric Lurand <elurand <at> free.fr> writes:

Partout où tu as besoin d'un cache particulier pour ton inclure (genre

#CACHE{0} par ex)

Je me souviens d'une remarque juste de spipcarto qui prohibait la balise cache à
zéro notamment pour parer la connexion de 2 internautes à quelques secondes.
Donc a minima cache à 15s par exemple...

J'avais du dire une betise alors car il me semble bien que #CACHE{0} force le calcul bien le calcul (toutefois, attention aux combinaisons statiques/dynamiques qui peuvent jouer des tours)

Maintenant je prefere utiliser un cache personnel meme avec un delai à 5 seconde car si l'utilisateur s'acharne sur son F5, il n'ecroule pas les acces base de données.

Rappel :
pour faire un cache personnel :

squelettes/bloc_perso.php :
<?php
//secu basique
if ((!isset($contexte_inclus['fond']) && !isset($contexte_inclus['fond']))
|| strstr($contexte_inclus['fond'], '..')
) die ("erreur bloc_perso : ".$contexte_inclus['fond']);

if (($GLOBALS['auteur_session']['statut']=="0minirezo")
||($GLOBALS['auteur_session']['statut']=="1comite")
||($GLOBALS['auteur_session']['statut']=="6forum")){
$contexte_inclus['auteur_session_id']=$GLOBALS['auteur_session']['id_auteur'];
$contexte_inclus['auteur_session_statut']=$GLOBALS['auteur_session']['statut'];
}

include _DIR_RESTREINT_ABS.'public.php';

?>

Et pour l'inclusion :
<INCLURE(bloc_perso.php{fond=xxx}>

On aura alors à dispo dans ces inclusions si l'auteur est authentifié :
#ENV{auteur_session_id} et #ENV{auteur_session_statut}

pour faire un cache par statut; il suffit de ne pas mettre auteur_session_id dans le contexte.

Avec ca, on est sur qu'un bout de cache contenant des données protégées ne sera pas renvoyer par erreur à quelqu'un qui n'y a pas droit.

On peut aussi se servir d'inclusions specifiques pour aller chercher des données dans un fichier de configuration et les mettre dans le contexte (je crois que biospip faisait ca il y a longtemps).

@++

d979d7e88876a434c7e2 · Mai 30, 2007, 3:19

Stanislas a écrit :

Fredo Mkb <fredomkb <at> free.fr> writes:

je me pose un certain nombre de questions, que je souhaite vous soumettre, pour avoir votre avis

Je me suis souvent demandé aussi si l'ordre des critères dans une boucle avait
une incidence sur la rapidité... ou si le critère {id_mot=2} était plus
performant que {titre_mot=edito}...

ESJ a bien optimisé les requetes, donc {id_mot} doit etre moins couteux que {titre_mot} et {type_mot} qui obligent une jointure de plus sur la requete.

Maintenant, si tu as une centaine de mots, c'est faut pas se prendre la tete avec les id qui rendent les squelettes difficilement transposables alors qu'avec un titre_mot (qu'on doublera par prudence d'un type_mot ou qu'on prefixera), n'importe qui peut remettre le mot dans sa base pour utiliser le squelette sans avoir à faire de modifs.

@++

fil · Mai 30, 2007, 3:30

Je pense qu'on est en train de couper les cheveux en quatre là

#INCLURE présente d'autres caractéristiques des balises statiques ; la
plus importante est qu'on peut appliquer un filtre sur son résultat :
[a (#INCLURE{xxx}|filtre) b]

PS : Ceci dit, je ne suis pas sur d'avoir compris les dernieres
remarques de Fil sur l'invalidation du cache... je crois que
l'invalidation est assez brutale maintenant.

Oui, tout modification substantielle de la base de données (correction
d'un article, publication d'une brève etc) invalide tous les caches.
Ca ne les supprime pas du répertoire cache (ce qui permet de tenir le
choc d'une panne SQL, contrairement à "vider le cache"), mais en
fonctionnement normal ça va ignorer tous les fichiers cache datant
d'avant la date d'invalidation.

-- Fil

d979d7e88876a434c7e2 · Mai 30, 2007, 3:47

Fil a écrit :

Oui, tout modification substantielle de la base de données (correction
d'un article, publication d'une brève etc) invalide tous les caches.

oui, j'ai retrouvé le message.
en fait, à chaque forum posté, c'est tout le cache de spip qui est invalidé.
c'est dommage, j'aimais bien jouer avec le cache.

mais je ne désespère pas de faire un systeme d'invalidation plus fin, basé sur les id passés en contexte.

Ca ne les supprime pas du répertoire cache (ce qui permet de tenir le
choc d'une panne SQL, contrairement à "vider le cache"), mais en
fonctionnement normal ça va ignorer tous les fichiers cache datant
d'avant la date d'invalidation.

c'est un peu problematique pour faire des gros menus ou des blocs complexes avec des données plutot statistique.
On se retrouve à tout calculer en meme temps, au premier hit suivant un mouvement.
Si en plus, on ne fait que des #INCLURE, on risque de coincer le systeme si le temps de calcul depasse la limite (30s par defaut).

Mais en fait, meme avec des squelettes compliqué, je n'ai jamais rencontré le probleme.
Les trucs les plus longs sont les calculs d'images et ils finissent par se faire.
Bref, le jour ou le besoin se posera, on y reflechira, c'est de toutes facons pas sorcier de surcharger l'invalidation.

@++

fil · Mai 30, 2007, 3:58

mais je ne désespère pas de faire un systeme d'invalidation plus fin,
basé sur les id passés en contexte.

Le système actuel reste codé et est encore réactivable d'une ligne
dans mes_options.

Mais d'une part il coûte cher lorsqu'on calcule (il faut stocker une
tonne d'invalideurs dans spip_caches), et d'autre part ESJ pense avoir
démontré qu'il était impossible "en théorie" d'en avoir un qui marche
vraiment.

Au total je serais pour le virer totalement ; son seul usage
actuellement (dans la branche dev) c'est de maintenir la "taille
courante du cache" pour le purger régulièrement et dans l'ordre.

-- Fil

d979d7e88876a434c7e2 · Mai 30, 2007, 4:15

Fil a écrit :

mais je ne désespère pas de faire un systeme d'invalidation plus fin,
basé sur les id passés en contexte.

Le système actuel reste codé et est encore réactivable d'une ligne
dans mes_options.

zut, j'ai pas noté, c'etait quoi deja ?

Mais d'une part il coûte cher lorsqu'on calcule (il faut stocker une
tonne d'invalideurs dans spip_caches), et d'autre part ESJ pense avoir
démontré qu'il était impossible "en théorie" d'en avoir un qui marche
vraiment.

oui sans contrainte de codage, mais si on sait ce qu'on fait, ca peut etre tres utile et efficace.
En gros, l'idée, c'est que les boucles ne dependant pas directement du contexte n'est pas garantie synchrone.
Si on se contraint à passer par des inclusions à chaque fois que le contexte change, c'est de la durée de mise en cache qu'on peut se passer.
Le seul probleme, c'est que ca fait beaucoup de caches et des invalidations massives et complexe (ce qui me parait plus problematique que le temps pris pour noter les caches).
Mais si on se contente comme aujourd'hui d'invalider sans detruire, et qu'on fait le menage en tache de fond, ca peut etre interessant.

Franchement une invalidation maitrisée, c'est interessant pour certaines configuration (en particuliers des gros sites avec des forums actifs)
Mais ca necessite un peu de reflexion à la conception des squelettes

Au total je serais pour le virer totalement ; son seul usage
actuellement (dans la branche dev) c'est de maintenir la "taille
courante du cache" pour le purger régulièrement et dans l'ordre.

Ben c'est clair en tous cas qu'une durée de mise en cache, ca n'a pas vraiment de sens...

@++

fil · Mai 30, 2007, 4:51

> Le système actuel reste codé et est encore réactivable d'une ligne
> dans mes_options.

zut, j'ai pas noté, c'etait quoi deja ?

ah la flemme, c'est un mal terrible, heureusement qu'on peut juste
poser la question sans chercher par soi-même :

# grep invalid ecrire/inc_version.php
// Faut-il "invalider" les caches quand on depublie ou modifie un article ?
# invalidants. (fonctionnalite experimentale : decommenter ci-dessous)
#$invalider_caches = 'id_article,id_breve,id_rubrique,id_syndic';
$invalider_caches = '';
// Autre approche : tout invalider si modif
$derniere_modif_invalide = true;

Franchement une invalidation maitrisée, c'est interessant pour certaines
configuration (en particuliers des gros sites avec des forums actifs)

Est-ce prouvé ? Ce que je constate sur les sites que je connais,
c'est que, si tu as un fort trafic, il est concentré sur quelques
pages. Et du coup même si tu invalides souvent tu tombes quand même
souvent dans le cache.

-- Fil

d979d7e88876a434c7e2 · Mai 30, 2007, 5:12

Fil a écrit :

ah la flemme, c'est un mal terrible, heureusement qu'on peut juste
poser la question sans chercher par soi-même :

# grep invalid ecrire/inc_version.php

oui, j'avoue que je suis surtout un peu bete, maintenant tout est la.
Merci.

Franchement une invalidation maitrisée, c'est interessant pour certaines
configuration (en particuliers des gros sites avec des forums actifs)

Est-ce prouvé ?

Ben, je ne vois pas ce qu'il y a à prouver.
Avec le nouveau systeme, c'est le hit suivant le dernier post de forum qui va se palucher le recalcul de tous les inclure.

L'avantage de séparer ces recalcul (par des invalidations ou des delais de cache), c'est qu'ils vont statistiquement se répartir sur des plusieurs hits.

Bref, il n'y aura pas un gars qui attendra 45s mais 3 qui attendront 15.

Ce que je constate sur les sites que je connais,
c'est que, si tu as un fort trafic, il est concentré sur quelques
pages.

Oui mais je parle de forums actifs.
J'ai un article avec 1 poste dans le forum toutes les 2mn d'un coté, et de l'autre des milliers de rubriques et d'articles très consultés.

toutes les 2mn, des gens qui consultent se tapent un recalcul, y compris les menus avec des boucles hierarchie, mots clé et j'en passe, juste parce qu'un gars a posté à l'autre bout du site.
C'est dommage sur le principe.

Maintenant, ca joue quand meme son role car ca limitera la charge serveur, mais c'est loin d'etre optimum.

Ce sont des cas particuliers dont les specificités doivent etre prises en compte à la conception du squelette, mais ou une invalidation ciblée est amha plus efficace.

Pour prendre un autre exemple, sur un site en 1.9.2, j'ai modifié la gestion des mots clés pour invalider rubrique (ce qui n'aura de sens que quand j'aurai mis le bon parametre dans mes_options) lorsqu'on lui affecte un mot.
C'est particulier, je calcule le squelette et les feuilles de style en fonction des mots clés, mais ca prouve qu'une invalidation ciblée, ca peut avoir un sens.

Et du coup même si tu invalides souvent tu tombes quand même
souvent dans le cache.

Encore une fois, le plus gros probleme que j'y vois, c'est le recalcul integral au premier hit.
C'est le seul truc que je vois qui puisse s'averer bloquant (si on utilise exclusivement des #INCLURE avec des trucs compliqués dedans)

Mais bon, ca marche vachement bien quand meme...

@++

fil · Mai 30, 2007, 7:01

Oui mais je parle de forums actifs.
J'ai un article avec 1 poste dans le forum toutes les 2mn d'un coté, et
de l'autre des milliers de rubriques et d'articles très consultés.

C'est quel site ?

C'est particulier, je calcule le squelette et les feuilles de style en
fonction des mots clés, mais ca prouve qu'une invalidation ciblée, ca
peut avoir un sens.

Oui, c'est pour ça que j'hésite à supprimer tout le code comme ça. Ce
n'est satisfaisant ni d'un côté ni de l'autre.

Mais bon, ca marche vachement bien quand meme...

S'il faut 45 s (voire même 15 s) pour préparer une page, c'est
vraiment pas terrible.

-- Fil