[spip-dev] Taille du dossier CACHE/

Coucou,

sur le Diplo le CACHE/ fait 1.1 Go... ;-(

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 ?

-- Fil

Coucou,
sur le Diplo le CACHE/ fait 1.1 Go... ;-(

Sur un hébergeur c'est terrible (on est souvent très limité en volume),
sur un serveur dédié c'est pas si grave, ça fait juste perdre un peu de
place sur le disque.

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...

C'est clair.

il va falloir trouver un mécanisme de limitation de l'espace disque occupé
par le cache.
Des idées ?

Stocker les infos de création dans une table SQL (fichier + date +
volume) et quand la somme dépasse une certaine valeur (par exemple un
multiple du nombre d'article, modifiable) virer les documents les plus
anciens. Pour optimiser le calcul de la somme on peut la stocker dans un
spip_meta que l'on modifie à chaque fois.

Coté efficacité, la technique classique de gestion d'un cache est
d'avoir deux seuils : un seuil à ne pas dépasser (par exemple 500Mo) et
un seuil de travail (par exemple 400Mo). Quand le cache dépasse 500Mo,
on vide jusqu'à atteindre 400Mo. Ca évite d'avoir un cache qui oscille
sans arrêt autour d'une valeur (j'ajoute un article, j'en retire un
autre et ainsi de suite sans arrêt).

A priori tout cela pourrait être fait dans "ecrire_fichier_cache"
(inc-cache.php3).

Autres soucis que je vois dans cette solution :
1) éviter les problèmes de concurrence (avec un lock, c'est sans doute
   faisable)
2) pour gérer les possibilités de conflit lors du calcul de la somme et
   de son stockage dans un spip_meta qui ferait que la valeur finirait
   par diverger de la vraie somme, remettre cette somme à la bonne
   valeur (calcul via SQL) à la fin d'un nettoyage.

Avantage : la table fichier+date+taille permettrait d'avoir un outils
statistique de gestion du cache, éventuellement (y'en a sur cette liste
qui semblent aimer les stats :wink:

Voila mes premières idées de la matinée :slight_smile:

a+

A priori tout cela pourrait être fait dans "ecrire_fichier_cache"
(inc-cache.php3).

OK

Autres soucis que je vois dans cette solution :
1) éviter les problèmes de concurrence (avec un lock, c'est sans doute
   faisable)

De concurrence à quel niveau ? La décision de vidanger ? la vidange
elle-même ?

2) pour gérer les possibilités de conflit lors du calcul de la somme et
   de son stockage dans un spip_meta qui ferait que la valeur finirait
   par diverger de la vraie somme, remettre cette somme à la bonne
   valeur (calcul via SQL) à la fin d'un nettoyage.

Bonne idée, on peut se permettre une petite dérive, si on remet les
compteurs à la bonne valeur de temps en temps.

Avantage : la table fichier+date+taille permettrait d'avoir un outils
statistique de gestion du cache, éventuellement (y'en a sur cette liste
qui semblent aimer les stats :wink:

Hé hé :wink:

-- Fil

sur le Diplo le CACHE/ fait 1.1 Go... ;-(

Pourquoi ";-(" ?
Ca correspond à de vraies pages ou pas ?
Vu la taille de la base c'est un peu énorme comme expansion
lors du passage au HTML... (x20)

Ca correspond à de vraies pages ou pas ?

Non, ça correspond à des tas d'URLs pourries. Quand un moteur se lance à
faire n'importe quoi... c'est peut-être aggravé par mes inc-urls, mais le
problème est bien présent dans le spip de base : si tu aspires
méthodiquement article.php3?id_article=$x pour tout $x compris entre 1 et
10000000 tu finis par faire exploser n'importe quel site spip (chut, ne le
répétez pas !)

Vu la taille de la base c'est un peu énorme comme expansion
lors du passage au HTML... (x20)

Voui.

-- Fil

Ca correspond à de vraies pages ou pas ?

Non, ça correspond à des tas d'URLs pourries. Quand un moteur se lance
à faire n'importe quoi... c'est peut-être aggravé par mes inc-urls,

En général, les URLs pourries correspondent à des liens internes
faussés mais qui renvoient une vraie page à cause de rewrite-rules
trop laxistes.

Exemple sur l'ancien minirezo.net : il y avait un lien interne foireux
vers "minirezo.net" (sans le http://). Résultat, une foultitude d'URLs
du genre :

http://www.minirezo.net/minirezo.net/minirezo.net/article123.html

se retrouvaient indexées dans Google. Bien qu'incorrectes ces URLs,
renvoyaient un contenu valide (un article dans le cas ci-dessus).

Je ne pense pas que les moteurs "sérieux" s'amusent à inventer des
URLs pour tester. Il faudrait regarder l'IP dans les logs pour vérifier
que ce n'est pas un petit malin (voire quelqu'un qui a besoin de cette
fonctionnalité dans SPIP :-))).

mais le problème est bien présent dans le spip de base : si tu aspires
méthodiquement article.php3?id_article=$x pour tout $x compris entre 1
et 10000000 tu finis par faire exploser n'importe quel site spip (chut,
ne le répétez pas !)

Si tu veux faire exploser un SPIP, tu peux aussi lancer des tonnes de
requêtes en ajoutant "?recalcul=oui" à la fin....

http://www.minirezo.net/minirezo.net/minirezo.net/article123.html
se retrouvaient indexées dans Google. Bien qu'incorrectes ces URLs,
renvoyaient un contenu valide (un article dans le cas ci-dessus).

Oui, c'est un cas parmi d'autres.

Je ne pense pas que les moteurs "sérieux" s'amusent à inventer des
URLs pour tester. Il faudrait regarder l'IP dans les logs pour vérifier
que ce n'est pas un petit malin (voire quelqu'un qui a besoin de cette
fonctionnalité dans SPIP :-))).

Pas mal de gens utilisent des programmes "aspirateurs", sans parler des
moteurs, et il y a vraiment de tout.

Si tu veux faire exploser un SPIP, tu peux aussi lancer des tonnes de
requêtes en ajoutant "?recalcul=oui" à la fin....

Ca n'est pas la même attaque. Ajouter ?recalcul, c'est une attaque délibérée
de type déni de service... l'autre cas ça peut être un robot qui part en
vrille...

-- Fil

si tu aspires méthodiquement article.php3?id_article=$x pour tout
$x compris entre 1 et 10000000 tu finis par faire exploser n'importe
quel site spip (chut, ne le répétez pas !)

Les articles qui n'existent pas sont quand même mis en cache ???

-Nicolas

Oui, car la fonction qui appelle le calcul lance le squelette en
question et met le resultat du calcul dans un fichier cache. Impossible
de savoir si ce calcul est ou non concluant...

Plus précisément, le fait que l'article n'existe pas est en soi une
conclusion :wink: Est-elle digne d'être mise en cache, that is the question,
mais ça devient Shakespearien... bref, ne finassons pas ; s'il faut borner
la taille du cache pour une bonne raison, bornons la.

-- Fil

Plus précisément, le fait que l'article n'existe pas est en soi une
conclusion :wink: Est-elle digne d'être mise en cache, that is the question,
mais ça devient Shakespearien... bref, ne finassons pas ; s'il faut borner
la taille du cache pour une bonne raison, bornons la.

Une chose que l'on peut faire pour finasser, c'est éventuellement de passer
la date du cache à "très vieux" si un id_xxx est appelé mais que l'objet
n'est pas publié. Comme ça, dès sa republication la page est recalculée. Ca
résoudrait ce bug que j'ai constaté à plusieurs reprises, d'une page
totalement vide parce que la base a bien connecté, entrainant le reclacul de
la page, mais pas réussi à répondre positivement au SELECT * FROM
spip_articles...

-- Fil

Oui, il ne faut pas que deux vidanges aient lieu en même temps. Il faut
que la gestion de la table "spip_cache" soit assez clean pour éviter
qu'il ne reste dans cette table des références à des fichiers qui
n'existent plus (la réciproque sera facile à gérer amha). Ceci dit, ce
n'est pas extremement grave, mais autant éviter ces dérives qui sont un
peu délicates à corriger.

Autre conflit : vidanger un fichier cache qui est en train d'être
envoyé... Aïe. Là, je me déclare assez incompétent... :frowning:

Enfin, il serait sans doute inutile et un peu dangereux de vidanger les
skel_*. Donc n'avoir une vidange que sur les caches des pages
elle-mêmes. Ca tombe bien j'ai l'impression c'est deux fonctions
séparées. Ouf : je n'ai rien dit :wink:

a+

Plus précisément, le fait que l'article n'existe pas est en soi une
conclusion :wink:

OK.

Est-elle digne d'être mise en cache, that is the question,
mais ça devient Shakespearien...

Vu que la réponse est la même pour tous les éléments qui n'existent pas, il
faudrait dans l'idéal qu'il n'y ait qu'une page en cache pour ce cas là ...

bref, ne finassons pas ; s'il faut borner la taille du cache pour
une bonne raison, bornons la.

Si on peut éviter l'explosion du cache avec un premier contrôle sur
l'opportunité de mettre en cache une page donnée, ce sera déjà beaucoup de
gagné, je pense.

-Nicolas

il faudrait dans l'idéal qu'il n'y ait qu'une page en cache pour ce cas
là ...

Bah ? non ! la réponse est codée dans le squelette...
<BOUCLE...></BOUCLE...>
réponse en question
</B...>

Bin pour déterminer quel squelette utiliser, on cherche déjà en base
l'élément, donc on sait tout de suite qu'il n'existe pas, non ???

-Nicolas

il faudrait dans l'idéal qu'il n'y ait qu'une page en cache pour ce
cas là ...

Bah ? non ! la réponse est codée dans le squelette...
<BOUCLE...></BOUCLE...>
réponse en question
</B...>

Bin pour déterminer quel squelette utiliser, on cherche déjà en base
l'élément,

Non (sauf dans le cas du diplo :wink:

Bin pour déterminer quel squelette utiliser, on cherche déjà en
base l'élément,

Non (sauf dans le cas du diplo :wink:

Comment dans ce cas sais-tu qu'il faut utiliser "article-42.html" plutôt
que "article.html" comme squelette ???

-Nicolas

> Bin pour déterminer quel squelette utiliser, on cherche déjà en base
> l'élément,
Non (sauf dans le cas du diplo :wink:

Ca n'est pas entièrement faux : on cherche en base toute la hiérarchie des
rubriques, pour appliquer éventuellement le squelette article-xxx.html.

Mais avec l'idée de Nicolas, on ne parle plus de chercher en base à chaque
calcul du cache, mais à chaque appel de la page (plus de cache, donc). C'est
ça qui ne va pas.

-- Fil

Comment dans ce cas sais-tu qu'il faut utiliser "article-42.html"
plutôt que "article.html" comme squelette ???

Ah, ok. Bon, c'est vrai, en fait l'élément est en effet recherché ;-))

Tu me rassures, j'ai cru que j'étais bon pour la camisole !!!

Note que parfois il m'en faudrait une ... :wink:

-Nicolas

A mon avis c'est trop compliqué, alors que ça n'est pas la bonne
fonctionnalité (celle qui nous donnera un cache de taille bornée).

@ Thomas NOEL <thomas.noel@auf.org> :

Adaptons son idée : faisons le test seulement si le cache n'existe
pas...?

.../...

Est-ce jouable ainsi ?

-- Fil