Bonjour,
Hier, j'avais un site ralenti.
Le cache faisait 660Mo et 140 000 fichiers !
Le site a 800 articles.
Dans le mes_options.php, j'avais :
$quota_cache = 200;
Je l'ai passé à 25.
Et ce matin, le cache est remonté à 371Mo !
b_b me faisait remarquer sur IRC que SPIP "essaye" de ne pas dépasser la valeur du quota. Mais là, ce n'est pas un essais, c'est un échec...
* RealET tapuscrivait, le 27/03/2009 09:54:
Bonjour,
Hier, j'avais un site ralenti.
Le cache faisait 660Mo et 140 000 fichiers !
Le site a 800 articles.Dans le mes_options.php, j'avais :
$quota_cache = 200;Je l'ai passé à 25.
Et ce matin, le cache est remonté à 371Mo !
b_b me faisait remarquer sur IRC que SPIP "essaye" de ne pas dépasser la valeur du quota. Mais là, ce n'est pas un essais, c'est un échec...
Une première précision : l'admin de SPIP m'indique que le cache fait 102Mo pour 391Mo réels :
La taille du cache est actuellement de 102 Mo.
En regardant le code source, la page servant à vider le cache calcule la taille du cache avec :
http://doc.spip.org/@taille_du_cache
Alors que http://doc.spip.org/@appliquer_quota_cache utilise nombre_de_fichiers_repertoire
Donc, 2 méthodes de calcul différentes (manifestement pour des questions de performance).
J'ai modifié sur le serveur appliquer_quota_cache pour que les logs de cette fonction soient à part de spip.log (dans quota.log).
Plus d'infos tout à l'heure...
Lorsque le sous système disque est trop lent, et qu’il y a trop de fichiers, le cron n’arrive plus à purger assez vite.
Je crois que cela se produit particulièrement sur les sites contenant potentiellement des urls en nombre tres grand par rapport au contenu (ie, pagination, agenda …) que les moteurs peuvent alors parcourir sans vergogne, generant des tonnes de fichier cache.
Comme par ailleurs ces mêmes robots n’executent pas forcèment le cron (qui est insere en image background sur un div), seuls les vrais visiteurs le font.
Un déséquilibre fort entre nombre de pages vues par les moteur et nombre de pages vues par les visiteurs provoque donc cela irremediablement.
Cédric
Cédric Morin a écrit :
Lorsque le sous système disque est trop lent, et qu'il y a trop de fichiers,
le cron n'arrive plus à purger assez vite.Je crois que cela se produit
particulièrement sur les sites contenant potentiellement des urls en nombre
tres grand par rapport au contenu (ie, pagination, agenda ...) que les
moteurs peuvent alors parcourir sans vergogne, generant des tonnes de
fichier cache.
Comme par ailleurs ces mêmes robots n'executent pas forcèment le cron (qui
est insere en image background sur un div), seuls les vrais visiteurs le
font.
Un déséquilibre fort entre nombre de pages vues par les moteur et nombre de
pages vues par les visiteurs provoque donc cela irremediablement.
C'est embêtant mais que peut on contre la gloutonerie des robots ?
Y aurait il une solution pour améliorer
sans détecter qu'un crawler est un robot ?
(comme le font certains plugins ou sites contre le spam)
Si on sait que c'est un robot qui consulte une page
on peut lui servir alors une version dégradée du site,
avec des squelettes simplifiés et ajustés précisément
pour que le robot maintienne ses bons services de robot
d'une manière peu consommatrice de ressources
et qui ne pénalise pas les services du site aux humains.
Par exemple lui servir uniquement les pages "de tête de gondole"
ou de la sitemap (et les liens qui vont vers)
ou lui servir les pages sans mise en page et sans accessoires
et sans mise en cache.
Mais c'est un peu du cloaking white hat, un peu chaud.
JL
Cédric Morin a écrit :
Lorsque le sous système disque est trop lent, et qu’il y a trop de fichiers,
le cron n’arrive plus à purger assez vite.Je crois que cela se produit
particulièrement sur les sites contenant potentiellement des urls en nombre
tres grand par rapport au contenu (ie, pagination, agenda …) que les
moteurs peuvent alors parcourir sans vergogne, generant des tonnes de
fichier cache.
Comme par ailleurs ces mêmes robots n’executent pas forcèment le cron (qui
est insere en image background sur un div), seuls les vrais visiteurs le
font.
Un déséquilibre fort entre nombre de pages vues par les moteur et nombre de
pages vues par les visiteurs provoque donc cela irremediablement.C’est embêtant mais que peut on contre la gloutonerie des robots ?
Au hasard :
Ou si tout cela est absolument indispensable :
utiliser des liens nofollow bien sentis pour éviter que les robots ne parcourent tout
desactiver le cache si on a vraiment peu de traffic ?
purger le cache chaque nuit avec un cron système ?
se payer un serveur bien dimensionné ?
en prendre son parti …
bref, on peut beaucoup …
Y aurait il une solution pour améliorer
sans détecter qu’un crawler est un robot ?
(comme le font certains plugins ou sites contre le spam)Si on sait que c’est un robot qui consulte une page
on peut lui servir alors une version dégradée du site,
avec des squelettes simplifiés et ajustés précisément
pour que le robot maintienne ses bons services de robot
d’une manière peu consommatrice de ressources
et qui ne pénalise pas les services du site aux humains.Par exemple lui servir uniquement les pages « de tête de gondole »
ou de la sitemap (et les liens qui vont vers)
ou lui servir les pages sans mise en page et sans accessoires
et sans mise en cache.
Ca ne fera qu’empirer les choses en multipliant les versions en cache d’une meme page
Cédric
Cédric Morin a écrit :
- Eviter d'avoir blocs paginés sur la même page qui multiplient d'autant le nombre d'url à parser pour les robots (4 blocs pagineés avec 10 pages chacun => 10*10*10*10 = 10000 pages)
A vue de nez, la fonction affine serait plutôt une fonction de puissance... donc...
4 pagination de 10 items = 10^10^10^10 non ?
J'ose même pas calculer... 
non, non …
va vite me réviser tes cours de combinatoire ! 
Cédric
Cédric Morin a écrit :
C'est embêtant mais que peut on contre la gloutonerie des robots ?
Au hasard :
- Eviter d'avoir un nombre infini de pages avec des &truc=xxx qui s'ajoutent
à l'infini (navigation en boucle erronée, erreur plus courante qu'on veut
bien le croire)
- Eviter d'avoir des (mini) calendriers sur lesquels on peut naviguer mois
par mois de la naissance du monde à sa disparition...
- Eviter d'avoir blocs paginés sur la même page qui multiplient d'autant le
nombre d'url à parser pour les robots (4 blocs pagineés avec 10 pages chacun
=> 10*10*10*10 = 10000 pages)
- Eviter d'avoir un sedna qui cumule tout celaOu si tout cela est *absolument* indispensable :
- utiliser des liens nofollow bien sentis pour éviter que les robots ne
parcourent tout
- desactiver le cache si on a vraiment peu de traffic ?
- purger le cache chaque nuit avec un cron système ?
- se payer un serveur bien dimensionné ?
- en prendre son parti ...bref, on peut beaucoup ....
En effet. Ce sont là de précieuses recommandations !
Gageons qu'on va voir des commits en résulter...
Et les var_nomdetruc ?
Je n'ai pas encore expérimenté ces parametres qui ne multiplient pas les caches,
mais peut être ils peuvent être mis à contribution ici ?
Comment sont ils pris en compte dans un squelette qui lui est caché ?
Faut passer par du php ? des #EVAL ?
Par exemple lui servir uniquement les pages "de tête de gondole"
ou lui servir les pages sans mise en page et sans accessoires
et sans mise en cache.Ca ne fera qu'empirer les choses en multipliant les versions en cache d'une
meme page
ben non, si ya pas mise en cache...
JL
* RealET tapuscrivait, le 27/03/2009 10:19:
* RealET tapuscrivait, le 27/03/2009 09:54:
Bonjour,
Hier, j'avais un site ralenti.
Le cache faisait 660Mo et 140 000 fichiers !
Le site a 800 articles.Dans le mes_options.php, j'avais :
$quota_cache = 200;Je l'ai passé à 25.
Et ce matin, le cache est remonté à 371Mo !
b_b me faisait remarquer sur IRC que SPIP "essaye" de ne pas dépasser la valeur du quota. Mais là, ce n'est pas un essais, c'est un échec...Une première précision : l'admin de SPIP m'indique que le cache fait 102Mo pour 391Mo réels :
La taille du cache est actuellement de 102 Mo.En regardant le code source, la page servant à vider le cache calcule la taille du cache avec :
http://doc.spip.org/@taille_du_cache
Alors que http://doc.spip.org/@appliquer_quota_cache utilise nombre_de_fichiers_repertoireDonc, 2 méthodes de calcul différentes (manifestement pour des questions de performance).
J'ai modifié sur le serveur appliquer_quota_cache pour que les logs de cette fonction soient à part de spip.log (dans quota.log).
Plus d'infos tout à l'heure...
Donc
Mar 27 10:44:13 92.140.154.7 (pid 21470) Taille du CACHE estimee (9): 72.3 Mo
Mar 27 10:44:15 92.140.154.7 (pid 21470) sites/carmel.asso.fr/tmp/cache/9/ : 0 caches supprimes
Mar 27 11:04:33 212.23.175.66 (pid 23309) Taille du CACHE estimee (a): 74.2 Mo
Mar 27 11:04:34 212.23.175.66 (pid 23309) sites/carmel.asso.fr/tmp/cache/a/ : 3995 caches supprimes
Mar 27 11:24:41 195.83.225.167 (pid 25233) Taille du CACHE estimee (b): 111.1 Mo
Mar 27 11:24:42 195.83.225.167 (pid 25233) sites/carmel.asso.fr/tmp/cache/b/ : 3883 caches supprimes
Mar 27 11:45:30 79.91.74.159 (pid 26985) Taille du CACHE estimee (c): 68 Mo
Mar 27 11:45:31 79.91.74.159 (pid 26985) sites/carmel.asso.fr/tmp/cache/c/ : 4101 caches supprimes
Mar 27 12:06:14 79.86.20.96 (pid 28961) Taille du CACHE estimee (d): 90.9 Mo
Mar 27 12:06:15 79.86.20.96 (pid 28961) sites/carmel.asso.fr/tmp/cache/d/ : 4402 caches supprimes
Mar 27 12:31:41 86.212.188.182 (pid 31031) Taille du CACHE estimee (f): 299.9 Mo
Mar 27 12:31:42 86.212.188.182 (pid 31031) sites/carmel.asso.fr/tmp/cache/f/ : 4115 caches supprimes
Mar 27 12:36:15 79.91.213.50 (pid 31400) Taille du CACHE estimee (0): 213.8 Mo
Mar 27 12:36:15 79.91.213.50 (pid 31400) sites/carmel.asso.fr/tmp/cache/0/ : 7793 caches supprimes
Mar 27 12:38:01 99.239.216.75 (pid 31892) Taille du CACHE estimee (1): 143.3 Mo
Mar 27 12:38:02 99.239.216.75 (pid 31892) tmp/cache/1/ : 6821 caches supprimes
Mar 27 12:40:56 81.56.246.184 (pid 32198) Taille du CACHE estimee (2): 77.5 Mo
Mar 27 12:40:56 81.56.246.184 (pid 32198) tmp/cache/2/ : 3265 caches supprimes
* Cédric Morin tapuscrivait, le 27/03/2009 11:31: