Author: marcimat@free.fr
Date: 2008-07-07 20:55:31 +0200 (lun, 07 jui 2008)
New Revision: 12002
Log:
- Supprimer les caches de sql_getfetsel() et sql_fetsel_cache() dès qu'il y a une modification dans la base par sql_insert*, sql_replace* ou sql_update*.
Introduction de deux fonctions :
* sql_fetsel_en_cache() qui stocke le cache de la fonction sql_fetsel_cache.
* sql_purge_cache() qui purge le cache de la fonction précédente.
Modified:
spip/ecrire/base/abstract_sql.php
Le 7 juil. 08 à 20:55, marcimat@free.fr a écrit :
Author: marcimat@free.fr
Date: 2008-07-07 20:55:31 +0200 (lun, 07 jui 2008)
New Revision: 12002Log:
- Supprimer les caches de sql_getfetsel() et sql_fetsel_cache()
Je n'avais pas vu passer cette histoire de cache dans les fonctions de l'API SPIP/SQL, et je ne suis pas très content de voir que ça n'a pas été signalé dans l'article
http://www.spip.net/ecrire/?exec=articles&id_article=3683
surtout que le moteur de recherche de Trac ne semble rien fournir au mot "cache" à ce propos.
Voila pour la forme. Pour le fond, je suis désolé mais je pense que c'est une mauvaise idée. Par principe, on n'implémente pas un cache dans un contexte d'accès concurrents sur lesquels on a aucune mécanisme de verrouillage. On peut bien purger le cache à chaque sql_update du PROCESSUS COURANT, mais qu'est-ce qui garantit qu'un processus concurrent ne va pas son sql_utpdate sur la même donnée ? Ce truc va générer des bugs aléatoires incompréhensibles. Il FAUT virer tout ça de cette API. C'est au développeur de gérer ses caches, ça ne doit pas faire parti d'une API d'un tel contexte.
Emmanuel
Hello,
c'est moi qui suit la cause de cela est c'était encore experimental.
Le constat est que sur un hit public on génère beaucoup de requêtes identiques sur les calculs des fonds (on requête id_rubrique, id_parent, lang a foison), des urls propres (arborescentes en particulier) etc ...
En regardant cela avec var_profile=1 j'avais vu qu'on pouvait déjà gagner beaucoup en évitant de refaire les mêmes requêtes sql simples qui passent beaucoup par sql_getfetsel(), d'où l'ajout.
Après, plusieurs questions se posent :
- mysql a en principe son propre cache, est-ce pertinent de le doubler dans SPIP, memes pour des reqêtes simples et répétitives ?
- on peut aussi cacher au niveau de la fonction appelante. Je l'ai fait notamment pour les url arborescentes.
Mais pour le calcul d'une page SPIP cela s'y prête mal car on a des appels semblables à plein d'endroits.
Je crois que tu as raison sur la problématique des accès concurrents. A ce niveau on ne maîtrise pas la criticité de la fraîcheur de l'info, et j'ai sous estimé ce point.
Il est donc plus sage de l'enlever pour la sortie.
La question reste posée car actuellement on dépense beaucoup d'énergie à requêter les mêmes infos sur les hits publics qui ne sont pas en cache, notamment au moment du choix du squelette, et quand on a une cascade d'inclusion, l'écart est sensible
Cédric
Le 7 juil. 08 à 21:53, Committo,Ergo:sum a écrit :
Le 7 juil. 08 à 20:55, marcimat@free.fr a écrit :
Author: marcimat@free.fr
Date: 2008-07-07 20:55:31 +0200 (lun, 07 jui 2008)
New Revision: 12002Log:
- Supprimer les caches de sql_getfetsel() et sql_fetsel_cache()Je n'avais pas vu passer cette histoire de cache dans les fonctions de l'API SPIP/SQL, et je ne suis pas très content de voir que ça n'a pas été signalé dans l'article
SPIP
surtout que le moteur de recherche de Trac ne semble rien fournir au mot "cache" à ce propos.Voila pour la forme. Pour le fond, je suis désolé mais je pense que c'est une mauvaise idée. Par principe, on n'implémente pas un cache dans un contexte d'accès concurrents sur lesquels on a aucune mécanisme de verrouillage. On peut bien purger le cache à chaque sql_update du PROCESSUS COURANT, mais qu'est-ce qui garantit qu'un processus concurrent ne va pas son sql_utpdate sur la même donnée ? Ce truc va générer des bugs aléatoires incompréhensibles. Il FAUT virer tout ça de cette API. C'est au développeur de gérer ses caches, ça ne doit pas faire parti d'une API d'un tel contexte.
Emmanuel
_______________________________________________
spip-team@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-team
Le 7 juil. 08 à 22:36, cedric.morin@yterium.com a écrit :
- on peut aussi cacher au niveau de la fonction appelante. Je l'ai fait notamment pour les url arborescentes.
Mais pour le calcul d'une page SPIP cela s'y prête mal car on a des appels semblables à plein d'endroits.
Je crois que tu as raison sur la problématique des accès concurrents. A ce niveau on ne maîtrise pas la criticité de la fraîcheur de l'info, et j'ai sous estimé ce point.
Il est donc plus sage de l'enlever pour la sortie.La question reste posée car actuellement on dépense beaucoup d'énergie à requêter les mêmes infos sur les hits publics qui ne sont pas en cache, notamment au moment du choix du squelette, et quand on a une cascade d'inclusion, l'écart est sensible
Tout ce boulot là, c'est au compilo de le faire, car il peut estimer si la fraîcheur est un pb ou pas. Dans le cas que tu soulèves, il est d'ailleurs normal que le compilo considère que certaines valeurs n'ont pas le droit de changer au cours d'une inclusion, donc il ferait une mise en cache vue comme un verrouillage local et tout le monde serait content.
C'est une gros truc à développer évidemment (le compilo ne fait actuellement aucune optimisation de type partage de code). En attendant, comme tu dis, il faut le faire au niveau de la fonction appelante, et garder une API simple et fiable.
Emmanuel
Le 7 juil. 08 à 22:36, cedric.morin@yterium.com a écrit :
Je crois que tu as raison sur la problématique des accès concurrents. A ce niveau on ne maîtrise pas la criticité de la fraîcheur de l'info, et j'ai sous estimé ce point.
Il est donc plus sage de l'enlever pour la sortie.
Hello,
J'ai revert ces petits caches-misères en http://trac.rezo.net/trac/spip/changeset/12005.
--
MM.