Nous avons remarqué des comportements que nous n’arrivons pas à expliquer avec le cache de SPIP :
Lorsqu’on clique sur “recalculer la page”, la page est bien rafraichi sur mon navigateur mais ne l’est pas sur les autres ordinateurs (le cache du navigateur est bien vide). Il a fallu que je me connecte à l’interface privé et que je vide le cache via la configuration du site pour que tous les autres clients voient une page actualisé (avec un simple F5).
Notre site est limité à 1Go de cache (limite définie par nous). Lorsque ces 1Go de cache sont atteind je suppose que SPIP va supprimer certains fichiers dans le répertoire “cache” pour respecter ces limitation. Mais comment SPIP gère le très grand nombre de fichiers ? Est ce pour cela que parfois notre cache dépasse allègrement les 1Go (parfois de plus de 300Mo) ? SPIP peut-il être saturé et ne pas arriver à gérer correctement son cache ?
Pour information si nous ne limitons pas le cache, nous montons à 10Go de cache.
Est ce que les robots des moteurs de recherches (Google, Yahoo, Bing, etc) vont générer du cache ? Comme ces moteurs sont censés balayer l’ensemble du SPIP, le cache va automatiquement se re-remplir très vite.
Que préconisez vous en matière de taille du cache ? Limité la taille ou laisser le cache grandir ?
Faut-il mettre en place un cron qui fait du nettoyage pour limiter les problèmes de cache ?
Le 6 juin 2012 à 16:43, Guillaume Le Bozec a écrit :
Bonjour,
Nous avons remarqué des comportements que nous n’arrivons pas à expliquer avec le cache de SPIP :
Lorsqu’on clique sur « recalculer la page », la page est bien rafraichi sur mon navigateur mais ne l’est pas sur les autres ordinateurs (le cache du navigateur est bien vide). Il a fallu que je me connecte à l’interface privé et que je vide le cache via la configuration du site pour que tous les autres clients voient une page actualisé (avec un simple F5).
#SESSION ou #AUTORISER dans la page provoquent des cache distincts. Le bouton « Recalculer » force la mise à jour du cache de l’admin qui voit la page, pas celle du cache du visiteur anonyme.
Notre site est limité à 1Go de cache (limite définie par nous). Lorsque ces 1Go de cache sont atteind je suppose que SPIP va supprimer certains fichiers dans le répertoire « cache » pour respecter ces limitation. Mais comment SPIP gère le très grand nombre de fichiers ? Est ce pour cela que parfois notre cache dépasse allègrement les 1Go (parfois de plus de 300Mo) ? SPIP peut-il être saturé et ne pas arriver à gérer correctement son cache ?
C’est une limite approximative, pas une limite stricte, et il peut donc arriver que le cache déborde quand un bot génère plein de fichiers cache plus vite que le cron ne supprime les vieux. Problème classique de baignoire avec un robinet qui coule vite par moment, et une bonde de diamètre fixe…
Pour information si nous ne limitons pas le cache, nous montons à 10Go de cache.
Est ce que les robots des moteurs de recherches (Google, Yahoo, Bing, etc) vont générer du cache ? Comme ces moteurs sont censés balayer l’ensemble du SPIP, le cache va automatiquement se re-remplir très vite.
Oui, comme tout visiteur. Ce pourrait être une stratégie de calculer le contenu sans mise en cache pour les bots, mais cela risque d’alourdir leur contribution à la charge serveur car tous les éléments communs aux pages semblables seront calculés autant de fois que de pages vues…
Que préconisez vous en matière de taille du cache ? Limité la taille ou laisser le cache grandir ?
Toujours avoir une limite, dont la taille est à ajuster au site, selon les besoins (complexité du squelette, nombre de pages différentes, trafic, utilisations de caches sessionnés…)
Faut-il mettre en place un cron qui fait du nettoyage pour limiter les problèmes de cache ?
Il y en a déjà un dans SPIP. Après il peut être utile de l’appeler plus souvent ou en tache système (cf le problème de baignoire : cela permet d’augmenter la taille du trou d’écoulement)
Cela veut-il dire qu’on ne peut pas contrôler le cache d’un article ?
Par exemple si on a besoin qu’un article précis ne soit pas dans le cache suite à une modification éditoriale de cet article, on n’a pas la possibilité de le faire ? C’est soit on vide entièrement le cache, soit on attend que SPIP gère avec le temps ?
Le 6 juin 2012 17:14, Guillaume Le Bozec <g.lebozec@gmail.com> a écrit :
Par exemple si on a besoin qu'un article précis ne soit pas dans le cache
suite à une modification éditoriale de cet article, on n'a pas la
possibilité de le faire ? C'est soit on vide entièrement le cache, soit on
attend que SPIP gère avec le temps ?
Depuis SPIP 2 (si je ne me trompe pas) le cache est invalidé par les
modifications faites dans la partie privée.
De plus on peut contrôler la durée du cache des squelettes grâce à la
balise #CACHE#CACHE - SPIP
Justement le problème est là. Il ne nous semble pas que le cache soit invalidé par des modifications effectuées dans la partie privée du site et que le cache persiste après modification pour l’ensemble de nos clients.
Le 6 juin 2012 17:28, Guillaume Le Bozec <g.lebozec@gmail.com> a écrit :
Justement le problème est là. Il ne nous semble pas que le cache soit
invalidé par des modifications effectuées dans la partie privée du site et
que le cache persiste après modification pour l'ensemble de nos clients.
Si comme conseillé plus tôt tu es allé lire: http://thread.gmane.org/gmane.comp.web.spip.devel/62862 tu as dû voir
qu'il est recommandé pour les gros caches d'utiliser le plugin
memoization qui gère mieux la multiplicité des fichiers.
- Notre site est limité à 1Go de cache (limite définie par nous). Lorsque ces 1Go de cache sont atteind je suppose que
SPIP va supprimer certains fichiers dans le répertoire "cache" pour respecter ces limitation. Mais comment SPIP gère le
très grand nombre de fichiers ? Est ce pour cela que parfois notre cache dépasse allègrement les 1Go (parfois de plus de
300Mo) ? SPIP peut-il être saturé et ne pas arriver à gérer correctement son cache ?
Pour information si nous ne limitons pas le cache, nous montons à 10Go de cache.
Il doit y avoir un paquet de fichiers dans le cache
ce qui ralentit certainement les opérations du filesystem.
Peut être le plugin memoization que _fil_ a développé améliorerait il ce point précis.
En effet ce plugin propose un mode filecache qui porte le nombre de répertoire de stockage
des fichiers caches à 256x256.
Répartis dans ce beaucoup plus grand nombre de répertoires, les fichiers caches sont moins nombreux dans chaque répertoire, et le filesystem est beaucoup plus agile.
Si on sait pertinemment que maintenant, dans SPIP, on a plus de
fichiers parce que l'usage des balises #SESSION et #AUTORISER s'est
démocratisé, pourquoi ne pas adapter le cache natif à ce fait ?
Est-ce que l'on prévient suffisamment les utilisateurs de ces balises
dans la doc officielle ?
Est-ce que l'on prévient suffisamment les utilisateurs de ces balises
dans la doc officielle ?
Il y a un plugin "mémoization" qui permet de dépasser les limitations
naturelles du cache "à l'ancienne" de SPIP et d'utiliser des méthodes
plus efficaces. Il "suffit" peut-être de le proposer dans
plugins-dist/ ; en tous cas pour nos amis qui ont des problèmes de
cache, je recommande d'essayer ce plugin et ses diverses méthodes de
cache.
Le plugin Memoization indique (dans le fichier filecache.inc) :
// file named tmp/cache/ab/cd
// that's a maximum of 16^4 files in 256 directories
Si je comprends bien, cela représente 65 536 fichiers.
Sur un site (réel) qui a 16 000 articles avec 6 fichiers de cache par article
(squelette article avec 5 inclusions qui dépendent du numéro de l'article),
on est déjà à 96 000 fichiers.
Aussi, le nombre de 65 536 fichiers risque d'être trop limité.
ou pas...
Le cache n'a pas vocation à stocker une copie de l'ensemble du site, mais uniquement des morceaux utilisés le plus fréquemment.
Donc à tester
Que'il faut mettre en place un cron système qui appelle celui de spip régulièrement.
Ou alors définir un nouveau mode 'powerfilecache' pour memoization,
ou un paramétrage du mode 'filecache' existant,
adapté aux spécificités de votre site ?
Si je comprends bien, cela représente 65 536 fichiers.
(...)
Aussi, le nombre de 65 536 fichiers risque d'être trop limité.
ou pas...
Le cache n'a pas vocation à stocker une copie de l'ensemble du site, mais uniquement des morceaux utilisés le plus fréquemment.
Donc à tester
Certes, mais ça pose quand même souci car les crawlers font facilement
augmenter le nombre de fichiers en cache en testant différentes
options de paramètre GET arbitrairement. Du genre essayer divers
id_mot sur des pages pour lesquelles ce paramètre n'est jamais utilisé
(et il n'existe aucun lien vers cette page avec un id_mot). Google le
fait par exemple.
Et si je comprends bien le fonctionnement, pour chaque valeur de XXX
dans l'URL du type http://monsite.tld/spip.php?page=truc&id_mot=XXX,
SPIP va créer un fichier de cache.
À cause de ça, il y a des sites dans lesquels seule une petite partie
des pages réelles (C'est à dire pas les copies avec des id_bidules
divers et non pertinents) se retrouve dans le cache. Au final le cache
devient assez peu rentable pour ces sites: le visiteur se trouve
souvent devant une page qui n'est pas en cache et qui devra être
calculée tandis que le cache est plein de pages qui ne seront jamais
visitées car ne correspondent à aucune URL atteignable depuis le web.
Je te propose de continuer la discussion quand tu auras testé memoization+xcache et que tu auras relevé les hits et les misses dans le cache (panneau d'admin de xcache) ou autre méthode équivalente pour avoir des statistiques des hits dans le cache et en dehors du cache.
On peut toujours imaginer que ça marche pas, ou se faire des scénario compliqués.
Mais discuter de stratégies de cache dans le vide ne mènera nul part.
