je suppose qu'un aspirateur a déraillé et fait n'importe quoi, mais on ne
peut pas laisser les choses partir comme ça sans contrôle... il va falloir
trouver un mécanisme de limitation de l'espace disque occupé par le cache.
Des idées ?
Il s'en était suivi une discussion sur l'opportunité de pouvoir gérer le
cache.
Il y a quelques mois mon hébergeur râlait car mon cache remplissait tout
l'espace qui m'était alloué.
J'ai augmenté mon espace disque et...me voilà à nouveau rendu à 2Go de
cache!
C'est vrai que beaucoup de nos utilisateurs aspirent le site pour le
consulter offline mais bon...c'est clair que ça pose problème à force là
Il y a une parade qui a été trouvée? Un moyen de pouvoir limiter la taille
du cache?
Il n'y a pas que les utilisateurs, il y a aussi les robots google & cie.
Un truc simple qui pourrait être implémenté, ce serait de ne générer la page
dans le cache que si les stats indiquent que cette page fait plus de n
consultations / jour.
C'est sur que l'idéal serait d'implémenter un LRU, m'enfin c'était une idée
comme ça pour faire simple
Sur les machines ou j'ai des sites SPIP j'ai accès aux crontab donc je
supprime tous les jours le cache qui a une date de création de plus de
7 jours... . Bon dans le cas d'un gonflage du cache ponctuel
(aspirateur) c'est vrai que ca ne sert pas à grand chose, mais
autrement ca permet de le garder à une taille raisonnable.
Il y a quelques mois mon hébergeur râlait car mon cache remplissait tout
l'espace qui m'était alloué.
J'ai augmenté mon espace disque et...me voilà à nouveau rendu à 2Go de
cache!
Deux gigots ?! C'est quoi ton site ? Il y a beaucoup d'articles ?
Tu devrais essayer la dernière version CVS, il y a un mécanisme
pour limiter les dégâts (mais deux gigots, c'est énorme, à moins
que tu sois le webmestre masqué de l'Humanité et des amateurs
de haricots blancs).
> Il y a beaucoup d'articles ?
Non, 1300 et quelques centaines de brèves
50Mo de base..pour 2Go de cache: c'est disproportionné...
Oui, à tout le moins. Tu devrais aller voir les fichiers du CACHE,
leur nom te renseignera peut-être sur le type de requêtes dont
il s'agit. Notamment, si tu as été trop large sur les rewrite
rules et qu'une URL erronée est indexée par les moteurs de
recherche, ça peut récursivement générer beaucoup d'URLs
foireuses.
(par exemple, si tonsite.com/tonsite.com/ affiche à tort le
contenu de tonsite.com, et que cette URL est présente sur une
de tes pages - par exemple à cause d'un forumiste distrait
qui aura mis une URL relative à la place d'une URL absolue -,
les moteurs de recherche vont se mettre à indexer :
50Mo de base..pour 2Go de cache: c'est disproportionné...
Oui, à tout le moins. Tu devrais aller voir les fichiers du CACHE,
Les 2Go? Morts, paix à leur âmes d'octets.
Par contre pour les nouveaux je vois déjà un problème :
Mes pages articles c'est une colonne de droite, une colonne de droite ET un
corps qui correspond à l'article.
Dans le cache CHAQUE colonne est rattachée à l'article au lieu d'être
incluse telle quelle.
leur nom te renseignera peut-être sur le type de requêtes dont
il s'agit. Notamment, si tu as été trop large sur les rewrite
rules et qu'une URL erronée est indexée par les moteurs de
recherche, ça peut récursivement générer beaucoup d'URLs
foireuses.
Pas de rewrite url.
(par exemple, si tonsite.com/tonsite.com/ affiche à tort le
contenu de tonsite.com, et que cette URL est présente sur une
de tes pages - par exemple à cause d'un forumiste distrait
qui aura mis une URL relative à la place d'une URL absolue -,
les moteurs de recherche vont se mettre à indexer :
Ah ...euh ...les forumistes mettent rarement des url (ils savent même pas
que ça existe et qu'on dit plutôt uri (http://www.w3.org/Addressing/) et
comme je reçois les messages du forum en direct je corrigerai si je vois
passer.
La colonne de gauche link vers plan.php3...et comme elle est calculée pour
chauqe article ou breve avec l'id de l'article ou de la breve...pouf pouf...
A noter aussi que mon site est dans un sous repertoire du premier site ce
qui donne deux adresses valables:
Par contre pour les nouveaux je vois déjà un problème :
Mes pages articles c'est une colonne de droite, une colonne de droite ET un
corps qui correspond à l'article.
Dans le cache CHAQUE colonne est rattachée à l'article au lieu d'être
incluse telle quelle.
Ca n'arrive que la première fois, ou si on refuse les cookies.
Malheureusement les moteurs de recherche, eux, ne risquent
pas d'accepter les cookies
Du coup ton cache va être pollué par des tas de PHPSESSID
à la noix de coco.
Il se pourrait que ce soit lié à ton système de paiement
pour les articles, non ?
Par contre pour les nouveaux je vois déjà un problème :
Mes pages articles c'est une colonne de droite, une colonne de droite ET un
corps qui correspond à l'article.
Dans le cache CHAQUE colonne est rattachée à l'article au lieu d'être
incluse telle quelle.
Dans mon squelette c'est juste [(#URL_ARTICLE)], étrange ça.
Ca n'arrive que la première fois, ou si on refuse les cookies.
Malheureusement les moteurs de recherche, eux, ne risquent
pas d'accepter les cookies
Du coup ton cache va être pollué par des tas de PHPSESSID
à la noix de coco.
Il se pourrait que ce soit lié à ton système de paiement
pour les articles, non ?
Pas au système allopass mais ptet bien avec phpsecure oui.
Visiblement il renvoie le PHPSESSID du dernier connecté...
Bof ça...
Merci : j'avais pas vu.
Fil a également écrit:
A tout hasard: PHPSESSID est négligé par la version CVS de SPIP dans son
calcul du num du fichier cache
