Mon site produisait des erreurs 503 à répétition, que webalyzer signalait en bloc (25% des requêtes http !),
et que les google webmaster tools précisaient, url par url.
Voici la réponse de l'hébergeur interrogé :
Dans config/ecran_securite.php, SPIP fait un test sur la charge du serveur, si elle est supérieure à 4, il envoie un 503 aux bots.
4 est une charge excessive pour un dual-core, mais .... le serveur web a 16 cores !
La solution est probablement de remplacer 4 par 8, vous ne devriez plus avoir de 503 ou presque.
Une valeur 4 en dur semble donc très contrindiquée !
Peut être y aurait il moyen de récupérer des infos sur le CPU et adapter ce seuil en conséquence ?
Si tu trouves quelque chose qui est portable et très léger (se calcule à chaque hit), pourquoi pas.
Autre possibilité, faire un define pou rce niveau 4, et le définir dans mes_options.php
Mais cela dit ce n’est pas grave de tenir les bots un peu à distance ; ils reviennent toujours, sans jamais se lasser…
Si tu trouves quelque chose qui est portable et très léger (se calcule à chaque hit), pourquoi pas.
Autre possibilité, faire un define pou rce niveau 4, et le définir dans mes_options.php
C'est déjà un define '_ECRAN_SECURITE_LOAD'
mais c'est planqué dans les profondeurs,
et la détection même du symptôme nécessite un examen attentif.
Une recherche google renvoie des réponses dépendant de l'OS :
sous linux
exec(“cat /proc/cpuinfo | grep processor | wc -l”,$processors);
sous freeBSD
sysctl -a | grep 'hw.ncpu' | cut -d ':' -f2
un code php tout prêt pour ces 2 systems :
même sans windows, ça couvre une belle majorité des serveurs.
Mais cela dit ce n'est pas grave de tenir les bots un peu à distance ;
ils reviennent toujours, sans jamais se lasser…
Effectivement, il n'y a que les bots qui ont pâti de ce sous-dimensionnement.
OK.
"Ce réglage active la protection anti-robots quand la charge du serveur (load) excède la valeur X. La valeur par défaut est 4 ; pour désactiver, mettre 0."
Tel quel, cela ne permet pas de comprendre quelle valeur mettre en dehors de 0 et de 4.
Il suffirait par exemple de reformuler ainsi : "[...] La valeur par déaut est 4, ce qui correspond à l'activité à 100% de 4 cores d'un CPU.[...]"
Et d'ajouter éventuellement : "Si le CPU de votre serveur a 16 cores, il sera préférable de mettre une valeur plus élevée, 8 par exemple."
Je ne suis pas du tout certain que ce soit "préférable". Si ton serveur
charge autant, pour quelle raison ? C'est là qu'il faudrait investiguer.
J'espère que ce n'est pas SPIP qui prend 4 coeurs à 100% en permanence (ou
alors, que tu as un trafic énorme). N'oublie pas que les requêtes services
aux robots sont souvent consommatrices en SQL, et que SQL devient
facilement un goulet d'étranglement…
"Ce réglage active la protection anti-robots quand la charge du serveur (load) excède la valeur X. La valeur par défaut est 4 ; pour désactiver, mettre 0."
Tel quel, cela ne permet pas de comprendre quelle valeur mettre en dehors de 0 et de 4.
Il suffirait par exemple de reformuler ainsi : "[...] La valeur par déaut est 4, ce qui correspond à l'activité à 100% de 4 cores d'un CPU.[...]"
Et d'ajouter éventuellement : "Si le CPU de votre serveur a 16 cores, il sera préférable de mettre une valeur plus élevée, 8 par exemple. »
Il ne faut pas confondre un Load de 4 et une charge CPU de 400%, il n’y a pas de correspondance directe.
En particulier le load reflète les processus en attente, ce qui n’est pas forcément à cause du CPU mais peut aussi être à cause des I/O (notamment d’un NFS).
La valeur de 4 n’est donc pas délirante et ne doit pas s’évaluer uniquement à l’aune du nombre de processeurs de la machine.
D’autant plus que le mécanisme d’allègement de l’écran de sécu s’active progressivement au fur et à mesure que le load dépasse la valeur seuil : à 4.01 de load il n’y aura quasiment aucune 503 d’envoyée.
C’est, en situation, une bonne valeur qui permet de garder une performance serveur satisfaisante et d’éviter de faire attendre le visiteur.
C'est dommage qu'il n'y ait pas d'annexe à la doc,
(comme dans la doc php, par exemple, qui intègre un forum de complément de doc en dessous de la doc originelle)
car elles y auraient eu leur place.
Merci pour ces précisions.
C'est dommage qu'il n'y ait pas d'annexe à la doc,
(comme dans la doc php, par exemple, qui intègre un forum de complément de
doc en dessous de la doc originelle)
car elles y auraient eu leur place.
tu peux toujours l'ajouter dans la doc directement, ou bien, si au final ça
fait trop à digérer, dans un article du carnet, avec un lien ?
Merci pour ces précisions.
C'est dommage qu'il n'y ait pas d'annexe à la doc,
(comme dans la doc php, par exemple, qui intègre un forum de complément de doc en dessous de la doc originelle)
car elles y auraient eu leur place.
tu peux toujours l'ajouter dans la doc directement,
Non, je n'ai pas les droits.
Je peux suggérer un texte à ajouter, mais cela me semble lourd comme manière de faire,
alors que probablement toutes les personnes ayant les droits sur la rédaction de spip.net
ont lu ce thread.
ou bien, si au final ça fait trop à digérer, dans un article du carnet, avec un lien ?
Je bénéficierai(s) ainsi de l'autonomie de rédaction sur le carnet,
et la lourdeur sera(it) limitée à la (demande de) création du lien sur spip.net/ecrire.
À cette étape de la discussion, ma remarque visait surtout à souligner un besoin
généralisable à toutes les pages de spip.net et s'adressait aux personnes qui mènent
une réflexion pour la refonte de spip.net
Merci pour ces précisions.
C'est dommage qu'il n'y ait pas d'annexe à la doc,
(comme dans la doc php, par exemple, qui intègre un forum de complément de doc en dessous de la doc originelle)
car elles y auraient eu leur place.
tu peux toujours l'ajouter dans la doc directement,
Non, je n'ai pas les droits.
Je peux suggérer un texte à ajouter, mais cela me semble lourd comme manière de faire,
alors que probablement toutes les personnes ayant les droits sur la rédaction de spip.net
ont lu ce thread.
ou bien, si au final ça fait trop à digérer, dans un article du carnet, avec un lien ?
Je bénéficierai(s) ainsi de l'autonomie de rédaction sur le carnet,
et la lourdeur sera(it) limitée à la (demande de) création du lien sur spip.net/ecrire.
À cette étape de la discussion, ma remarque visait surtout à souligner un besoin
généralisable à toutes les pages de spip.net et s'adressait aux personnes qui mènent
une réflexion pour la refonte de spip.net
+1 ooo
Il me semble meme qu'un champ url est tjrs disponible
Par contre, cela demandera un peu plus de réactivité
en mise-à-jour et "jardinage" dans les pages....
À cette étape de la discussion, ma remarque visait surtout à souligner un
besoin
généralisable à toutes les pages de spip.net et s'adressait aux personnes
qui mènent
une réflexion pour la refonte de spip.net
à cette étape de l'enfilade (thread en anglais) il est bon de préciser
qu'en attendant
la refonte, l'espace privé de spip.net est ouvert et l'on peu commenter en
dessous
de l'article et parfois même faire les modifications dans l'article. Pour
améliorer
cette documentation.
