Excusez-moi de revenir la dessus mais j'aimerais arriver à y voir plus clair, en particulier sur l'impact des items de pagination + ajax dans la question du fonctionnement du cache dans un site SPIP
Question 1 : Taille "normale" d'un cache
Excusez-moi de revenir la dessus mais j'aimerais arriver à y voir plus clair, en particulier sur l'impact des items de pagination + ajax dans la question du fonctionnement du cache dans un site SPIP
Question 1 : Taille "normale" d'un cache
Excusez-moi de revenir la dessus mais j'aimerais arriver à y voir plus clair, en particulier sur l'impact des items de pagination + ajax dans la question du fonctionnement du cache dans un site SPIP
Question 1 : Taille "normale" d'un cache
----------------------------------
De ce que j'ai pu voir des logs, c'est à priori bien un robot (msn.search) qui met de temps à autre en surchauffe le cache ... En ce moment, ce est stabilisé aux alentours de 300-400 Mo, ce qui me parait tout de même bien conséquent.
=> C'est normal qu'un cache SPIP ait un "volume de croisière" de cette importance ?
Ça dépend du nombre d'urls consultables sur ton site...
Question 2 : liens de pagination & ajax
---------------------------------
J'appelle classiquement les blocs "d'autres articles sur le même thème" par des inclure du type
<INCLURE {fond} {env} {ajax}>
Plusieurs blocs apparaissent et les url se gonflent donc très vite avec la présence de plusieurs "id_mot=ceci" et plusieurs "debut_pagination=cela"
Cette façon de faire, pourtant tout à fait basique, a-t-elle pour conséquence de créer autant de fichiers de cache qu'il n'y a de combinaisons ?
Tout a fait, puisque a chaque fois que l'url change, elle est passee par env, et donc le contexte de l'inclusion change, ce qui entraine un nouveau cache.
Si dans ton inclusion tu n'utilise nulle part l'url de la page en cours pour construire une nouvelle url, tu peux economiser du cache en remplacant le {env} par juste le {debut_xxx} correspondant au nom de ta pagination. C'est plus economique, mais a manier avec precaution, au cas par cas.
Si c'est ça, ça peut expliquer la taille respectable du cache car ça fait un paquet de combinaisons... et faut-il revoir la façon de faire ?
Quid de l'ajax pour naviguer dans les listes de résultats présentes dans chacun des blocs "sur le même thème" ? Ça multiplie encore les fichiers de cache ?
Non, l'ajax n'augmente pas le nombre de fichier cache. Ça aurait plutot tendance à le diminuer car seul le bloc que tu pagine va etre recalcule avec la nouvelle url, et pas tous les autres blocs de la page. Mais comme les robots n'utilisent pas ajax, eux font faire tous les calculs possibles.
C'est pour ça que l'ecran de securite bloque les robots qui font de la pagination multiple : des qu'il y a plus d'un debut_xx dans l'url, les robots reçoivent un code d'erreur 403 leur interdisant l'accès à la page.
Si dans ton cas tu utilise en plus des id_mot croisés etc, il faut peut être que tu sois plus sévère avec eux, ou que tu les redirige en n'acceptant qu'un seul id_mot ou debut_xx par url.
Dans ton mes_options, tu peux utiliser la constante _IS_BOT qui vaut true quand c'est un robot qui parcours la page :
if (_IS_BOT){
if (_request('id_mot') AND _request('debut_xxx')){
header("HTTP/1.0 403 Forbidden");
die("<html><title>Error 403: Forbidden</title><body><h1>Error 403</h1><p>You are not authorized to view this page</p></body></html>");
}
}
a adapter selon ton cas.
Cédric