Version 7 — Octobre 2018 — JLuc
La clé binaire se sauve pas en BDD
CACHE_KEY ne se sauve pas correctement sur une BDD, pourtant utf8, sur un site hébergé chez gandi. Du coup c’est vide quand on le récupère, et les caches ne sont pas cryptés. Ça ne se produit pas chez nursit par contre. C’est pas grave chez Gandi car les caches ne sont pas partagés mais sur un autre hébergement où ce problème se produit aussi et où les caches sont partagés, ce serait une faille sécu.
Caches dont la clé se termine par _
Pour certains squelettes , J’ai l’impression que memoization produit des paires de ces caches jumeaux : l’un suffixé par _, l’autre pas lorsqu’une personne logée visite un squelettes non sessionnés .
- Ces caches ont toujours une entrée [invalideurs][session] } mais vide.
Pour toutes ces personnes logées elle produit un cache suffixé par ’_’ distinct du cache pour les personnes non logées, qui n’a pas ce suffixe.
- Le Parfois le cache sans _ est quasi vide : il ne contient toujours que :
Array ([invalideurs] => Array ( [session] => ''), [lastmodified] => 1540217689)
- Le cache avec _ Ça sert à quoi ? est consulté prés de 2 fois plus souvent que celui sans _ ( 3281 / 2438 ) Est-ce utile ?
Parfois ces caches sont identiques. À confirmer !
Cela vient du fait
- que le cache non sessionné d’une personne logée contient quand même l’invalideur ’session’=>’’ (vide) À confirmer. Cela semble associé au fait - que Mémoization teste seulement < code>isset($cache[’invalideurs isset($cache[’invalideurs ’][’session’]) et non si la valeur est non-vide, pour ajouter le suffixe ’_idsession’. Tous ces caches ont une entrée
$cache['invalideurs']['session '] Est-ce normal ?
</code > dont ) et non la valeur ( qui est vide, et ça crée donc le suffixe '_'. ).
Hypothèses :
- le cache sans _ est une erreur de création (ou de test), et n'est pas utilisé. On peut ne pas le créer. (?)
- le cache sans _, qui contient presque rien, a une fonction annexe, comme un marqueur intermédiaire (?)
- ce sont les caches non sessionnés d'internautes logés (?)
Si nécessaire on peut corriger ça en corrigeant l'un ou l'autre de ces 2 points, mais il faudrait confirmer d'abord que ces 2 caches sont identiques dans tous les cas, et qu'il doit n'y en avoir qu'un seul.
{{Disponibilité trompeuse}}
Sur un hébergement <code>OVH mutu, le plugin détecte que memcached et memcache sont disponibles (ainsi que redis), mais en fait ils ne le sont pas. Selon la doc OVH memcached est « non activable », bien que php soit configuré avec « ’—enable-memcached ». Quand on active le plugin avec Memcached, le site fonctionne quand même, mais rame (30 secondes pour servir une page). Avec memcache, il ne rame pas autant mais met 2 fois plus de temps qu’avec filecache pour servir une page.
Le test de disponibilité devrait être plus précis.