Le 08/02/2018 à 12:14, JLuc a écrit :
Merci cerdic et marcimat pour vos réponses qui me permettent de voir les 
limites du truc
et comment préciser aussi.


Je répond ci après et commence à tester.

Voici un échantillon de résultats de mes premiers tests :
- filtrage lors du parcours :
        chemin preg_match (admin|prive|liste) OU contexte contient 
id_monobjet=18
- à un moment où le rendement du cache est de 87%
- 18000 caches APC parcourus et testés
- 225 chemins trouvés et 185 id_objet trouvés
- non distinction entre cache invalidés ou non (pour le test seulement)
- action entreprise sur les caches résultats : $d['lab_invalide']=true;

-> temps requis, tel qu'indiqué par microtime : 0.5 secondes
   (assez stable pour cette quantité de caches)

Cela infléchit il votre appréciation sur le rendement d'un tel effort,
dans la mesure où ça ne doit se faire qu'à chaque invalidation ?

Et le coût n'est plus que de 0.2 secondes si on ne teste pas id_monobjet=18
(car dans ce cas il n'y a pas besoin d'examiner les metadatas du contenu du 
cache).

Pour utiliser un tel mécanisme, il y a plein de paramètres ajustables :
- que faire des caches périmés : les vider ou les garder comme maintenant ?
Si on les vide, le parcours pour invalidation devient plus rapide  (moins de 
0.1 seconde)
car il y a bien moins de cache à parcourir
mais si on les garde on peut les utiliser en cas de pic (effet cachecool 
temporaire).
- enrichir le format de recherche de l'objet pour l'invalidation (accepter une 
suite d'objets)
- au contraire, simplifier le format de recherche du chemin pour éviter une 
regexp

JLuc

Le 07/02/2018 à 17:17, ced...@yterium.com a écrit :
Tu fais allègrement l’impasse sur mon calcul d’ordre de grandeur qui te montre justement qu’entre invalider un cache toutes les 10min et invalider un cache toutes les 6 heures tu optimise tout au plus 0.2% de tes hits. Même en supposant qu’un hit calcul est 10 fois plus couteux qu’un hit en cache, ça te fait un gain potentiel sur tes ressources serveurs de l’ordre de 2%, cela en supposant que ton énergie dépensée à gérer ton invalidation est nulle.

Effectivement je n'ai pas encore bien intégré ces ratios.

En pratique tout de même, l'efficacité n'atteint pas souvent de 98,5%.
Notamment pendant un usage intensif de l'admin-privé-backend,
les invalidations sont très fréquentes (une par minute par exemple).
Typiquement dans ce cas il serait utile de n'invalider que les squelettes de 
l'admin
- on peut affiner et préciser quelle partie de l'admin doit être invalidée -.

Moi je sais pas trop comment avec memoization tu fais pour dire « hé invalide moi tous les caches qui correspondent à l’article 18 » vu que justement c’est un système de stockage clé-valeur, donc tu n’as pas de relationnel ni de structure de requêtes pour ressortir un lot de cache etc.

Avec memoization on a un accés rapide au contexte (et à toutes les métadata) 
associées à un cache.
Il suffit de les passer tous en revue et voir s'il y a id_article=18 dans le 
contexte.
ça aurait été hyper lent avec filecache mais ça semble raisonnable avec APC 
Cache
(ou memcache ou reddis probablement).

Dans le cas où on veut invalider les squelettes d'un certain sous-dossier,
il n'y a pas besoin d'accéder au contexte, il suffit de tester le nom du cache,
qui intègre le chemin du cache.
D'où la proposition : que suivre_invalideur reçoive un argument
du format "id='objet/id_objet' chemin='regexp_nomducache'"

Dans mon cas pour le backend il faut tester s'il ya la chaine 'admin' dans le 
chemin.
Dans le cas du privé de spip, j'ai l'impression que la chaine 'prive' ne suffit 
pas
(la chaine 'prive' ne se retrouve dans le nom du cache que si c'est une 
noisette perso pour le privé)
Mais s'il y a à disposition un mécanisme d'invalidation ciblée comme ça,
on peut aussi, ensuite, construire les squelettes en conséquence.
Par exemple, dans mon cas, les squelettes de listes d'objets sont dans un 
dossier 'liste' :
ça tombe bien car c'est facile à cibler pour invalider chaque fois qu'on crée 
ou modifie un objet.

Pour les caches qui sont repérés,
on pourrait probablement les invalider spécifiquement en ajoutant un champ 
'valide' dans les metadata
(à tester dans la fonction qui vérifie la validité d'un cache)
mais en tout cas il est facile de les vider simplement (mais au détriment de 
cachecool)
et c'est ce que j'envisageais jusqu'à maintenant.

Par exemple si on veut que tous les squelettes de listes d'objets se mettent à 
jour dans le public
ainsi que les squelettes avec id_article=18 dans le contexte
ainsi que tout l'admin et le prive
on pourrait demander suivre_invalideur("id='article/18' 
chemin='liste|admin|prive'")

Maintenant si il s’agit de gérer le passage de certains pics de charge uniquement, tu peux avoir une stratégie relativement triviale et peu couteuse qui consiste à dire « si mon serveur est plus chargé que tel seuil et que j’ai un cache disponible qui date de moins de 24h je le considère valide même si mon flag derniere_modif me dit que normalement je devrais le mettre à jour »

En effet, ça semble assez simple à mettre en place.

Avec ça ton site fais le gros dos quand tu as un pic de charge et fonctionne 
nominalement le reste du temps.
Mais si ton serveur est constamment trop chargé tu perd l’invalidation du cache liés aux modifications éditoriales (et c’est là qu’il est important d’avoir quand même un délai maxi sur le cache, pour assurer que ton site se mettra quand même un peu à jour)

Pour apprécier "l'énergie" mise pour un filtrage je vais tester le coût d'un 
filtrage de cache
selon les critères "id_objet dans le contexte" et "chemin dans le nom"
(pour invalidation ciblée ou vidage ciblé)

JL

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



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

Répondre à