Re: [SPIP Zone] Plugin de cache efficace

From : cedric@... , the 7th February 2018 17:17

On 7 févr. 2018 à 15:18 +0100, JLuc , wrote:
 Le 07/02/2018 à 10:20, cedric@... a écrit :
  "There are only two hard things in Computer Science: cache invalidation and naming things."   — Phil KarltonOuf, on est pas seuls dans l'univers.
  Pour ce qui est de l’invalidation selective, c’est une usine à gaz qui n’a pour intérêt que de compliquer énormément toutes les choses.   Il faut se demande à quoi sert le cache et ce qu’on en attends : en l’occurence de la robustesse vis à vis des pics de charge et de l’indisponibilité éventuelle temporaire de la base de donnée.
 Ce sont des circonstances critiques mais relativement exceptionnelles  pour lequel le fonctionnement actuel est ok... pour autant que le pic ne dure pas.  Ce qui m'intéresse actuellement, c'est de diminuer la charge serveur au quotidien,  simplement pour bénéficier au mieux des ressources limitées dont on dispose  en s'en servant pour des tâches utiles, comme de "calculer du nouveau"  plutôt que de "calculer des trucs déjà connus dans le passé".
  Et donc du coup combien de charge et d’énergie tu peux allouer à la gestion de l’invalidation d’un cache pour ne pas être perdant ?
 Ok ce qu'il faut optimiser.
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.
  En pratique dès qu’on commence à dépenser de l’énergie à calculer quoi invalider on est perdant par rapport à   l’espérance de gain…
 Je n'ai pas encore cette pratique mais la décision SPIPienne de tout invalider à chaque changement  a été prise à une époque où la gestion du cache passait par la BDD  et où les caches étaient stockés dans des fichiers,  et c'était donc très coûteux.  Je ne me trompe pas sur le contexte dans lequel s'inscrivait de cette décision ?  Mais dans un autre contexte, avec un cache géré par mémoization par exemple,  les rapports sont très différents, car le coût d'interrogation du cache est bien moindre,  de même que le coût de son filtrage ou nettoyage ciblé.  As tu la pratique avec un cache géré par mémoization ?
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. Enfin moi je dis ça je dis rien… 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 » 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) -- Cédric