[SPIP Zone] [Spip-zone-commit] r108655 - in _plugins_/metaplus/trunk

cerdic · Janvier 31, 2018, 11:24

Achtung, decoder_url fait certes le job mais nécessite des requetes SQL, ce qui veut dire que tu introduit la dépendance à MySQL : chaque hit sur une page provoque une connexion mysql et une/des requetes (pas génialement rapide, en plus).

Pour ne pas avoir ce soucis, il faut que tu aies un cache là dessus.
Soit du fait main, soit tu utilises le cache de SPIP en créant un squelette que tu inclues avec l’URL pour seul contexte, et dans ce squelette tu appliques un filtre sur l’URL pour déterminer la page, l’inclusion whatever.

Ainsi le 2ème hit sur la même URL tombe sur du full cache sans requete SQL.

--
Cédric

On 26 janv. 2018 à 21:24 +0100, spip-zone-commit@rezo.net, wrote:

Author: tcharlss@bravecassine.com
Date: 2018-01-26 21:24:39 +0100 (Fri, 26 Jan 2018)
New Revision: 108655

Modified:
_plugins_/metaplus/trunk/inclure/metasplus/dist.html
_plugins_/metaplus/trunk/metasplus_options.php
Log:
Changement de tactique pour identifier la page. On n'utilise plus ['contexte'] qui n'est pas recomandée, et de toute façon dans le contexte retourné on ne pouvait pas identifier l'id de l'objet de façon fiable (quand il y avait plusieurs id_xxx dans l'URL). La seule fonction qui semble faire le job est recuperer_url, elle renvoie exactement ce dont on a besoin et de façon fiable. Au niveau des perfs, j'ai noté un temps d'execution entre 5ms et 15ms, ça me semble acceptable.

Details: Connexion · GitLab

_______________________________________________
Spip-zone-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone-commit

tcharlss · Janvier 31, 2018, 3:18

Merci pour les indications, je pense avoir saisi le principe (avec l’aide de RastaPopoulos :p).

rastapopoulos · Janvier 31, 2018, 3:27

Le 31/01/2018 à 12:24, cedric@yterium.com a écrit :

Pour ne pas avoir ce soucis, il faut que tu aies un cache là dessus.
Soit du fait main, soit tu utilises le cache de SPIP en créant un
squelette que tu inclues avec l’URL pour seul contexte, et dans ce
squelette tu appliques un filtre sur l’URL pour déterminer la page,
l’inclusion whatever.

Ainsi le 2ème hit sur la même URL tombe sur du full cache sans requete SQL.

Effectivement c'est un gros problème.

Mais déjà decoder_url() c'est capilotracté, et la solution que tu
proposes autant voire encore plus. Je réitère ce que je disais le 26 :
le problème d'origine reste que recuperer_fond qui permet de ne pas
avoir de problème de cache ne marche pas pour les squelettes racines.
Pour toute personne qui ne connait pas le tréfonds des arcanes (y
compris moi), donc 99,9% des gens , ça fait un truc illogique et pas
compréhensible.

Quel est donc la vraie solution propre ? Et si ça n'existe pas que
peut-on faire pour corriger recuperer_fond et avoir un comportement
cohérent partout ?

SPIP récupère déjà ces informations (quel est l'objet et son identifiant
suivant l'URL demandée), donc on les a bien quelque part déjà en amont.
On doit bien pouvoir trouver un moyen de les avoir à ce niveau quand on
est en train de travailler sur le contenu du <head> ou du squelette
racine, quelque soit le jeu de squelettes.

On a l'impression de perdre des informations en cours de route et de
devoir réinventer la roue… en moins bien, en carré.

--
RastaPopoulos

cerdic · Janvier 31, 2018, 4:46

Je crois que tu fais une petite erreur d’analyse :
le pipeline recuperer_fond est appelé après que le fond ait été évalué, et donc ce que tu fais dans ce pipeline est executé à chaque fois que le fond est chargé, même si il vient du cache.

Ça se comporte donc exactement pareil que affichage_final pour la page finale !

Ce qui te sauve, en général, c’est que le recupererer_fond est inclus par un appelant qui a lui aussi un cache, et ce que tu as fais dans le pipeline est mis dans le cache de l’appelant.
Mais il y a forcément un moment où il n’y a plus d’appelant du tout...

--
Cédric

On 31 janv. 2018 à 16:29 +0100, RastaPopoulos <rastapopoulos@spip.org>, wrote:

Le 31/01/2018 à 12:24, cedric@yterium.com a écrit :
> Pour ne pas avoir ce soucis, il faut que tu aies un cache là dessus.
> Soit du fait main, soit tu utilises le cache de SPIP en créant un
> squelette que tu inclues avec l’URL pour seul contexte, et dans ce
> squelette tu appliques un filtre sur l’URL pour déterminer la page,
> l’inclusion whatever.
>
> Ainsi le 2ème hit sur la même URL tombe sur du full cache sans requete SQL.

Effectivement c'est un gros problème.

Mais déjà decoder_url() c'est capilotracté, et la solution que tu
proposes autant voire encore plus. Je réitère ce que je disais le 26 :
le problème d'origine reste que recuperer_fond qui permet de ne pas
avoir de problème de cache ne marche pas pour les squelettes racines.
Pour toute personne qui ne connait pas le tréfonds des arcanes (y
compris moi), donc 99,9% des gens , ça fait un truc illogique et pas
compréhensible.

Quel est donc la vraie solution propre ? Et si ça n'existe pas que
peut-on faire pour corriger recuperer_fond et avoir un comportement
cohérent partout ?

SPIP récupère déjà ces informations (quel est l'objet et son identifiant
suivant l'URL demandée), donc on les a bien quelque part déjà en amont.
On doit bien pouvoir trouver un moyen de les avoir à ce niveau quand on
est en train de travailler sur le contenu du <head> ou du squelette
racine, quelque soit le jeu de squelettes.

On a l'impression de perdre des informations en cours de route et de
devoir réinventer la roue… en moins bien, en carré.

--
RastaPopoulos

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

JLuc · Janvier 31, 2018, 5:07

Le 31/01/2018 à 17:46, cedric@yterium.com a écrit :

Je crois que tu fais une petite erreur d’analyse :
le pipeline recuperer_fond est appelé après que le fond ait été évalué, et donc ce que tu fais dans ce pipeline est executé à chaque fois que le fond est chargé, même si il vient du cache.
Ça se comporte donc exactement pareil que affichage_final pour la page finale !

Ce qui te sauve, en général, c’est que le recupererer_fond est inclus par un appelant qui a lui aussi un cache, et ce que tu as fais dans le pipeline est mis dans le cache de l’appelant.
Mais il y a forcément un moment où il n’y a plus d’appelant du tout...

Ayant découvert et arpenté le contenu des caches à l'aide de xray,
il me semble qu'il y a un très gros paquet de données annexes dans les caches.
Est ce qu'il ne serait pas possible d'y ajouter aussi les infos de decoder_url,
afin de les y récupérer ensuite au besoin ?

Indépendamment de cela, dans la mesure où les résultats du pipeline qui appelle decoder_url
sont utilisés dans un squelette SPIP mis en cache SPIP,
est il critique que le pipeline gère aussi son propre cache interne pour les résultats de decoder_url ?

JL

--
Cédric

On 31 janv. 2018 à 16:29 +0100, RastaPopoulos <rastapopoulos@spip.org>, wrote:

Le 31/01/2018 à 12:24, cedric@yterium.com a écrit :

Pour ne pas avoir ce soucis, il faut que tu aies un cache là dessus.
Soit du fait main, soit tu utilises le cache de SPIP en créant un
squelette que tu inclues avec l’URL pour seul contexte, et dans ce
squelette tu appliques un filtre sur l’URL pour déterminer la page,
l’inclusion whatever.

Ainsi le 2ème hit sur la même URL tombe sur du full cache sans requete SQL.

Effectivement c'est un gros problème.

Mais déjà decoder_url() c'est capilotracté, et la solution que tu
proposes autant voire encore plus. Je réitère ce que je disais le 26 :
le problème d'origine reste que recuperer_fond qui permet de ne pas
avoir de problème de cache ne marche pas pour les squelettes racines.
Pour toute personne qui ne connait pas le tréfonds des arcanes (y
compris moi), donc 99,9% des gens , ça fait un truc illogique et pas
compréhensible.

Quel est donc la vraie solution propre ? Et si ça n'existe pas que
peut-on faire pour corriger recuperer_fond et avoir un comportement
cohérent partout ?

SPIP récupère déjà ces informations (quel est l'objet et son identifiant
suivant l'URL demandée), donc on les a bien quelque part déjà en amont.
On doit bien pouvoir trouver un moyen de les avoir à ce niveau quand on
est en train de travailler sur le contenu du <head> ou du squelette
racine, quelque soit le jeu de squelettes.

On a l'impression de perdre des informations en cours de route et de
devoir réinventer la roue… en moins bien, en carré.

--
RastaPopoulos

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

rastapopoulos · Janvier 31, 2018, 6:02

Le 31/01/2018 à 17:46, cedric@yterium.com a écrit :

Ce qui te sauve, en général, c’est que le recupererer_fond est inclus
par un appelant qui a lui aussi un cache, et ce que tu as fais dans le
pipeline est mis dans le cache de l’appelant.
Mais il y a forcément un moment où il n’y a plus d’appelant du tout...

Ah super déjà je comprends un peu mieux, merci !

N'en reste pas moins que SPIP fait déjà tôt la recherche des
informations utiles suivant l'URL demandé :
- quelle page est demandée
- quel objet si c'en est un
- quel id_objet si c'est une page d'objet

Pourquoi est-ce qu'on n'a pas toujours un moyen d'avoir ces informations
en permanence, dans la suite ? Notamment pour le squelette racine, pour
ne rien avoir à faire en doublon.

Je sais bien qu'on n'a pas un vrai routeur d'URL cohérent qui marche
pareil pour n'importe quel URL, mais il s'agit un peu de ça : une fois
que SPIP a fait sa recherche "URL => tel contexte", on devrait avoir ces
infos à disposition tout le long du reste. Non ?

Autre chose qui serait encore mieux : est-ce qu'il ne faudrait pas un
pipeline "post_evaluer_fond" ou plutôt "post_compiler_fond" ?
Autrement dit qui serait *après* la compilation (squelettes => php) mais
*avant* l'enregistrement de cette compilation dans un fichier de case.

Si je simplifie :

$page = recuperer_fond() {
$page = evaluer_fond() {
$page = compilation du langage SPIP

// Ajouter ici !
$page = pipeline('post_compiler_fond')

    enregistre_en_cache($page)
    return $page
  }

$page = pipeline('recuperer_fond')

gestion de l'ajax, lang, etc
return $page
}

--
RastaPopoulos

cerdic · Février 1, 2018, 9:23

On 31 janv. 2018 à 18:08 +0100, JLuc <jluc@no-log.org>, wrote:

Ayant découvert et arpenté le contenu des caches à l'aide de xray,
il me semble qu'il y a un très gros paquet de données annexes dans les caches.
Est ce qu'il ne serait pas possible d'y ajouter aussi les infos de decoder_url,
afin de les y récupérer ensuite au besoin ?

C’est le cas : decoder_url retourne un tableau $contexte qui est le #ENV du squelette racine qui inclue ensuite tous les autres

Indépendamment de cela, dans la mesure où les résultats du pipeline qui appelle decoder_url
sont utilisés dans un squelette SPIP mis en cache SPIP,
est il critique que le pipeline gère aussi son propre cache interne pour les résultats de decoder_url ?

Le problème est que l’appel à decoder_url lui même est ici fait à chaque hit, ce qui suppose une connexion à la base de données et des requêtes SQL à chaque hit et ruine la robustesse de SPIP vis à vis de SQL

--
Cédric

cerdic · Février 1, 2018, 9:34

On 31 janv. 2018 à 20:13 +0100, RastaPopoulos <rastapopoulos@spip.org>, wrote:

Le 31/01/2018 à 17:46, cedric@yterium.com a écrit :
> Ce qui te sauve, en général, c’est que le recupererer_fond est inclus
> par un appelant qui a lui aussi un cache, et ce que tu as fais dans le
> pipeline est mis dans le cache de l’appelant.
> Mais il y a forcément un moment où il n’y a plus d’appelant du tout...

Ah super déjà je comprends un peu mieux, merci !

N'en reste pas moins que SPIP fait déjà tôt la recherche des
informations utiles suivant l'URL demandé :
- quelle page est demandée
- quel objet si c'en est un
- quel id_objet si c'est une page d'objet

Pourquoi est-ce qu'on n'a pas toujours un moyen d'avoir ces informations
en permanence, dans la suite ? Notamment pour le squelette racine, pour
ne rien avoir à faire en doublon.

Parce que *justement* SPIP ne fait pas cette analyse à chaque hit, ce serait trop dispendieux.
Ce que fait SPIP :
Il prend l’URL telle quelle et regarde si un cache correspond à cette URL.
Si oui il inclue directement le cache concerné sans aucun calcul ni aucune connexion à la BDD

Si non, il décode l’URL (ce qui est « couteux ») puis calcule le squelette qui va bien avec son contexte etc.

Je sais bien qu'on n'a pas un vrai routeur d'URL cohérent qui marche
pareil pour n'importe quel URL, mais il s'agit un peu de ça : une fois
que SPIP a fait sa recherche "URL => tel contexte", on devrait avoir ces
infos à disposition tout le long du reste. Non ?

cf explication ci-dessus.
Mais ce qui serait peut-être possible, à vérifier, c’est que le contexte du squelette racine soit dans le cache, de façon à ce que lorsqu’on ressort le cache racine de la page directement depuis l’URL on soit capable d’apperler un récupérer_fond avec ce même contexte, ce que l’on ne sait pas faire actuellement
(affichage_final arrive après, mais sans aucun contexte existant)

Autre chose qui serait encore mieux : est-ce qu'il ne faudrait pas un
pipeline "post_evaluer_fond" ou plutôt "post_compiler_fond" ?
Autrement dit qui serait *après* la compilation (squelettes => php) mais
*avant* l'enregistrement de cette compilation dans un fichier de case.

Si je simplifie :

$page = recuperer_fond() {
$page = evaluer_fond() {
$page = compilation du langage SPIP

// Ajouter ici !
$page = pipeline('post_compiler_fond')

enregistre_en_cache($page)
return $page
}

$page = pipeline('recuperer_fond')

gestion de l'ajax, lang, etc
return $page
}

Je crois qu’il y a trop de confusion entre la compilation et le calcul, là…
La compilation arrive bien en amont, n’est faite qu’une fois, et est indépendante de tout contexte de calcul : elle consiste simplement à transormer le language SPIP en PHP. Donc tout ce que tu pourrais faire là c’est ajouter un apperl à une fonction PHP en plus dans le squelette, mais ça ne te donnerait rien de plus…

--
Cédric

rastapopoulos · Février 1, 2018, 12:56

Le 01/02/2018 à 10:34, cedric@yterium.com a écrit :

Mais ce qui serait peut-être possible, à vérifier, c’est que le contexte
du squelette racine soit dans le cache, de façon à ce que lorsqu’on
ressort le cache racine de la page directement depuis l’URL on soit
capable d’apperler un récupérer_fond avec ce même contexte, ce que l’on
ne sait pas faire actuellement

C'est en gros à ça que je pensais quand je disais "avoir ces
informations en permanence, dans la suite" : qu'on vienne du cache ou
pas, à partir du moment où SPIP a déjà réussi à trouver ces informations
en amont, et bien ça serait bien de les avoir en permanence par la suite.

Du coup il manque un truc oui, et il faudrait garder ce contexte
d'origine dans le cache pour ne jamais avoir à le rechercher de nouveau.

Si je simplifie :
…

Je crois qu’il y a trop de confusion entre la compilation et le calcul, là…
La compilation arrive bien en amont, n’est faite qu’une fois, et est
indépendante de tout contexte de calcul : elle consiste simplement à
transormer le language SPIP en PHP. Donc tout ce que tu pourrais faire
là c’est ajouter un apperl à une fonction PHP en plus dans le squelette,
mais ça ne te donnerait rien de plus…

Oui ok, et bien avant le cache HTML si tu veux. Après les requêtes
contextualisées (quand on a un ENV) et avant le cache HTML. Justement
pour être capable d'inscrire dans le cache des choses supplémentaires
qui ont aussi eu l'environnement-contexte, et que donc lorsque SPIP sort
des contenus sans SQL on a aussi nos ajouts, sans refaire des requêtes
après coup ?

Ya bien moyen d'augmenter le nombre de pipelines pour en avoir 1 ou 2 de
plus tout le long de la chaîne afin d'être plus complet, plus polyvalent
? Au lieu d'en avoir un seul unique tout à la fin quand tout est fini,
après le cache à chaque hit.

--
RastaPopoulos