IMPORTANT Signaler une erreur ou faire une suggestion

Super lent en ce moment
Ca semble venir des images:

Capture d’écran 2023-10-20 à 17.44.36.png (513.09 Kio) Consulté 5011 fois

Ce n'est pas le temps de génération

Super lent en ce moment

Je confirme.

Ca semble venir des images

Ah, la gestion des images sur Kikourou, tout un poème

[Mathias]

Super lent en ce moment
Ca semble venir des images:

étonnant...
c'est quoi ton outil ?
Comment faut-il lire le rapport : je comprends que les images, comme les js et les css, ne sont téléchargés qu'au bout de 21sec. Je suppose qu'il ne s'agit pas du temps de chargement de chaque image ???

Super lent en ce moment
Ca semble venir des images:

étonnant...
c'est quoi ton outil ?
Comment faut-il lire le rapport : je comprends que les images, comme les js et les css, ne sont téléchargés qu'au bout de 21sec. Je suppose qu'il ne s'agit pas du temps de chargement de chaque image ???

Mode développeur du navigateur. Ici Safari, mais Chrome a le même (F12) et probablement aussi Firefox

[Mathias]

Mode développeur du navigateur. Ici Safari, mais Chrome a le même (F12) et probablement aussi Firefox

ok, je ne trouvais pas les mêmes stats sur le mode dév de firefox, sur chrome c'est mieux.
mais je ne comprends toujours pas comment lire le graphique. Je suppose que 21sec ce n'est pas le temps de chargement d'une seule image...

ok, ce n'est pas le temps de génération de la page qui pose pb, mais je ne vois pas bien comment le chargement des images pourrait plomber l'affichage.

Et je ne vois rien de louche côté serveur...

[Mathias]

je suis tenté de rebooter... mais enfin, on n'est pas sous windows !!!

J’ai l’impression que c’est le temps de réponse qui est très lent parfois. J’essaie de regarder plus en détail demain mais je ne suis pas un spécialiste

[Mathias]

C'est moi ou ça va mieux ce matin ?

(ce qui ne résoudrait pas le pb : je n'ai rien fait à part redémarrer mysql et apache, à tout hasard...)

C'est moi ou ça va mieux ce matin ?

C'est toi

C'est moi ou ça va mieux ce matin ?

C'est toi

je coonfirme, c'est lent aussi chez moi. Bon, c'est pas extraordinairement gênant mais ça annonce peut être un souci plus grave....

Désolé, j'ai raté ce message...

Je copie-colle donc la réponse que je viens de faire sur un autre fil...

Est-ce que vous avez toujours cette impression de lenteur ?
Si oui, quel temps de calcul des pages est donné par Kikouroù (voir en bas de page, juste après "version mobile". En général c'est quelques centièmes de secondes...)

Comme écrit sur l'autre fil, j'ai l'impression que cela vient de l'appel à des URL externes (typiquement google-analytics.com).

Ces délais très longs n'existent pas sur certaines pages du site : par exemple si je clique sur la petite enveloppe quand je un MP non lu.

kiklent.jpg (19.33 Kio) Consulté 4929 fois

le temps indiqué en bas de la page est tout à fait normal, donc php fait son travail correctement, c'est ensuite ou avant qu'il y a une longue attente.

ça devient de plus en plus lent comme si on assistait à un engorgement progressif.....

Bon courage !

[Mathias]

Je constate dans les logs qu'il y a beaucoup de robots, dont chatgpt, tiens !
Mais rien d'autre de louche.
Ça m'étonnerait quand même que le problème vienne d'un afflux de robots.... c'est tout Kikouroù qui serait ralenti, y compris php...
Je suis en train de vérifier la santé des disques...

[Mathias]

charge élevée : uptime à 3, mais pourquoi ?
nb de process httpd au taquet (paramétré à 150), mais pourquoi ?
process mysql au top du "top", mais c'est sans doute normal (pas de souvenir de l'habituel)

si qqun a une idée... sinon je rebooterai ce soir, et alors : alea jacta est !

j'ai eu l'impression que c'étaient les avatars qui mettaient longtemps à se charger : j'ai eu une fois ou deux l'accès à des fils sans avatars, ceux ci se chargeant dans un deuxième temps.

Sinon l'activité principale ces derniers jours, ce sont les copier.coller du bouzin qui n'ont jusqu'à présent jamais provoqués ce type de lenteur

Je constate dans les logs qu'il y a beaucoup de robots, dont chatgpt, tiens !
Mais rien d'autre de louche.
Ça m'étonnerait quand même que le problème vienne d'un afflux de robots.... c'est tout Kikouroù qui serait ralenti, y compris php...
Je suis en train de vérifier la santé des disques...

Je ne pense pas trop à un problème sur le serveur de Kikouroù, mais en fait lorsque nos navigateurs chargent une page de KKR, il y a des tas d'appels vers des URL externes (notamment les pubs....et les traqueurs qui vont avec). J'imagine qu'il est possible qu'une de ces URL soit obsolète ou dysfonctionne. Les délais seraient alors, donc, entre nos navigateurs et ces URL externes, donc après que nos navigateurs aient reçu le contenu de la page qui vient de kikourou.net

https://www.webpagetest.org/vitals.php? ... ched=0#lcp

Le problème semble se situer sur ces 5 URL :

http://www.kikourou.net/css/kikourou.css
http://www.kikourou.net/include/jscripts/advertising.js
http://www.kikourou.net/css/home.css
http://www.kikourou.net/include/jscript ... m-event.js
http://www.kikourou.net/include/jscript ... ore-min.js

Exemple sur la première :
bubulle@kheops:~/tmp $ time wget -nd http://www.kikourou.net/css/kikourou.css
--2023-10-22 17:27:39-- http://www.kikourou.net/css/kikourou.css
Résolution de http://www.kikourou.net (http://www.kikourou.net)… 87.98.188.32
Connexion à http://www.kikourou.net (http://www.kikourou.net)|87.98.188.32|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 12784 (12K) [text/css]
Sauvegarde en : « kikourou.css.2 »

kikourou.css.2 100%[==============================================================================================================================================================================>] 12,48K --.-KB/s ds 0,02s

2023-10-22 17:28:00 (567 KB/s) — « kikourou.css.2 » sauvegardé [12784/12784]


real 0m21,612s
user 0m0,020s
sys 0m0,011s
bubulle@kheops:~/tmp $

ça y'en a pas normal de prendre 20 secondes pour transférer ceci :
bubulle@kheops:~/tmp $ ls -l kikourou.css
-rw-r--r-- 1 bubulle users 12784 27 déc. 2018 kikourou.css


Donc, je corrige mon message précédent : il est bien possible que le pb se situe sur le serveur. Pourquoi met-il autant de temps à envoyer ces braves pages CSS et ce code Javascript qui sont tout à fait raisonnables ? Un timeout de lecture sur le stockage? Si le serveur était un simple PC bidouillé dans le fond d'un appart' (comme le kheops d'où je fais ces tests), on pourrait dire qu'il y a un pb de lecture sur le disque où est le fichier kikourou.css....mais là, on est sur le stockage d'un truc hébergé, donc derrière ça doit être du stockage cloudifié

je râlais sur le site tout lent (surtout la première connexion quand il cherche les liens externes à priori, mais pas que, poster un message prends du temps aussi), mais je vois que des personnes bien compétentes sont sur le coup ! good luck !

edit:en fait c'est un peu aléatoire, des fois ça charge de suite, des fois on attend 10 secondes

je râlais sur le site tout lent (surtout la première connexion quand il cherche les liens externes à priori, mais pas que, poster un message prends du temps aussi), mais je vois que des personnes bien compétentes sont sur le coup ! good luck !

edit:en fait c'est un peu aléatoire, des fois ça charge de suite, des fois on attend 10 secondes

C'est probablement un effet de cache : si les fichiers à charger (les .CSS et les .JS) sont dans le cache du navigateur *et* en fonction des réglages de ce cache, cela peut ponctuellement masquer le défaut car le fichier n'est alors pas "redemandé" au site.

[Mathias]

Oui il y a un effet du cache.

Non ce n'est pas cloudifié : Kikouroù est hébergé sur un serveur dédié, avec donc ses propres disques durs. Lesquels sont un peu (bcp) anciens... et surtout, c'est du disque mécanique, pas du SSD. Donc bon, on pourrait fortement suspecter des erreurs d'accès disques.

Ce que je n'arrive pas à comprendre, c'est pourquoi ces lenteurs touchent les fichiers externes (qui font parfois 1 ou 2 ko) et pas le fichier php lui-même. Dans les 2 cas, apache a besoin d'aller chercher qques ko sur le disque...

Non ce n'est pas cloudifié : Kikouroù est hébergé sur un serveur dédié, avec donc ses propres disques durs. Lesquels sont un peu (bcp) anciens... et surtout, c'est du disque mécanique, pas du SSD. Donc bon, on pourrait fortement suspecter des erreurs d'accès disques.

Il serait vraiment temps de moderniser tout ça, ouvre une cagnotte Litchee.

C’est étonnant que ce soit toujours 20s

Le serveur a été redémarré ?
Cela pourrait permettre de voir si c’est un process fou qui bloque, non ?
Il y a pas d’outils pour voir l’état des disques durs ?

[Mathias]

Non ce n'est pas cloudifié : Kikouroù est hébergé sur un serveur dédié, avec donc ses propres disques durs. Lesquels sont un peu (bcp) anciens... et surtout, c'est du disque mécanique, pas du SSD. Donc bon, on pourrait fortement suspecter des erreurs d'accès disques.

Il serait vraiment temps de moderniser tout ça, ouvre une cagnotte Litchee.

Ce n'est pas un pb d'€, malheureusement, ce serait trop simple.
C'est le serpent de mer du nouveau serveur Kikouroù...
Cela fait des mois que le futur nouveau serveur Kikouroù est dispo, je paye donc 2 serveurs en parallèle, sans trouver le bon moment, comme d'hab, pour dégager suffisamment de temps pour faire le transfert.
Ce n'est pas un si gros boulot que ça, mais ça n'a pas été fait depuis 12 ans (!!!) et ça nécessite tout un tas de compétences technico-techniques, qui nécessite que je me replonge dans le bazar, ça prend du temps...

[Mathias]

C’est étonnant que ce soit toujours 20s

Le serveur a été redémarré ?
Cela pourrait permettre de voir si c’est un process fou qui bloque, non ?
Il y a pas d’outils pour voir l’état des disques durs ?

Non, pas encore. Je tente d'explorer d'autres pistes avant de redémarrer, si on peut éviter c'est mieux... ce n'est pas un vulgaire windows qu'on redémarre tous les 4 matins
Tant que ça tourne, ça tourne. Si je redémarre, qui sait ce qui peut se passer ?

Non, je ne vois pas de process qui bloque, juste un mysql qui consomme bcp de CPU me semble-t-il. Mais si c'était vraiment la cause du pb, le temps de génération des pages serait aussi impacté.
J'ai lancé une analyse des disques, ça prend des plombes...

ouais, mais là, je ne sais pas le problème mais c'est vraiment problématique ces temps de réponse.

[Mathias]

En attendant, je tente un truc tout bête : passer de 150 à 250 le nb de process httpd en parallèle.
Il y avait en effet saturation : 150 process en parallèle en permanence.
Comme je ne vois aucune raison pour que cette limite pose problème maintenant et pas avant, je pense que les process httpd s'empilent les uns après les autres à cause d'un pb d'accès aux fichiers, et donc qu'augmenter la limite ne fera que repousser le pb.

Sauf que pour l'instant ça semble fonctionner, le nb de process reste aux alentours de 230.
ça m'échappe...

Faut-il incriminer ces saletés de robots ? Pour quelle raison se mettraient-ils subitement à lancer plus de requêtes en parallèle ? Est-ce que chatgpt pourrait être le responsable ? (je ne l'avais pas vu passer dans les logs, jusqu'à présent...)

ça semble effectivement bien mieux

Ha oui, c'est revenu utilisable !
il y a pas des threads bloqués ou autre truc du genre ?

Est-ce qu'il y a beaucoup plus de connexions (de robots) qu'avant expliquant une augmentation des sessions apache, ou est-ce que c'est des threads bloqués ou autre qui empêchent les sessions apache de se libérer ? zatiz ze kwestion

[Mathias]

Je ne sais pas...

Mais au-delà de la question de la poule et de l'oeuf, je m'interroge surtout sur ce qui pourrait bien faire attendre 20sec l'accès à une image de qques ko, sans ralentir significativement la génération des pages PHP.

Vérification cette après-midi : pas de secteur défectueux que les disques.

Le nb de process httpd reste sous la limite de 250, mais ça me semble tout de même anormalement élevé entre 200 et 230.

Je n'ai pas cherché pour de vrai, juste vite fait pour voir ce qu'apache pouvait avoir comme timeout de 20" par défaut. Et je tombe sur ces histoires de reqtimeout. Sauf que dans ce cas si ça kille la connexion au bout 20" on ne devrait pas pouvoir afficher la page demandée... bref je pose ça là quand-même
https://superuser.com/questions/935942/apache-drops-connection-after-20-seconds
https://httpd.apache.org/docs/2.4/mod/mod_reqtimeout.html

[Mathias]

Je n'ai pas cherché pour de vrai, juste vite fait pour voir ce qu'apache pouvait avoir comme timeout de 20" par défaut. Et je tombe sur ces histoires de reqtimeout. Sauf que dans ce cas si ça kille la connexion au bout 20" on ne devrait pas pouvoir afficher la page demandée... bref je pose ça là quand-même
https://superuser.com/questions/935942/apache-drops-connection-after-20-seconds
https://httpd.apache.org/docs/2.4/mod/mod_reqtimeout.html

ouaip. Merci, mais, non, ça ne colle pas.
De plus, quand je relance apache, le nb de process augmente progressivement jusqu'à ~200, et dans ce cas là on voit que le temps de téléchargement d'une image augmente progressivement.
Je n'ai pas l'impression qu'il y ait un timeout de 20 sec quelque part...

C'est plus lent ce soir....

Et c'est confirmé par le test :

https://www.webpagetest.org/result/2310 ... view_step1 --> start render au bout de 11,7 secondes

Lors de mon premier test avec webpagetest.org, c'était 42,5 secondes, y'a du mieux, mais il faudrait retester à nouveau demain soir, et ainsi de suite....

798 connectés au cours des 5 dernières minutes.
à mon avis, il faut regarder les logs pour bannir quelques ip des robots inutiles.

[Mathias]

798 connectés au cours des 5 dernières minutes.
à mon avis, il faut regarder les logs pour bannir quelques ip des robots inutiles.

Bien vu !
Après avoir passé pas mal de temps à regarder les logs système, je n'ai regardé les logs apache que cette après-midi... je ne pensais pas que le souci pouvait venir de là, cf. :

Faut-il incriminer ces saletés de robots ? Pour quelle raison se mettraient-ils subitement à lancer plus de requêtes en parallèle ? Est-ce que chatgpt pourrait être le responsable ? (je ne l'avais pas vu passer dans les logs, jusqu'à présent...)

Le truc inédit, c'est l'ampleur de "l'attaque", parce que oui, à ce niveau là ça ressemble presque à une attaque DDoS...

[Mathias]

à mon avis, il faut regarder les logs pour bannir quelques ip des robots inutiles.

Le truc inédit (il me semble) c'est que ce bot (bytedance, un chinois, même boîte que tik tok), en plus d'ignorer le robots.txt, est très agressif et capable de changer de plage IP et même de pays.

Ces jours-ci, il accaparait 65% du trafic de Kikouroù !

Je l'ai banni via une regexp sur le user-agent directement dans le httpd.conf
Inconvénient : il peut continuer à envoyer des centaines de requêtes par minute, et donc solliciter apache. Qui l'envoi paître avec une erreur 403, mais quand même, ce serait mieux de gérer ça avec le firewall...

Le jour où un mec malveillant quelque part dans le monde stockera des données personnelles sur tout le monde et les utilisera à des fins dictatoriales...
Ah, mince, on y est déja en Chine? Vite, je change de pseudo

798 connectés au cours des 5 dernières minutes.
à mon avis, il faut regarder les logs pour bannir quelques ip des robots inutiles.

Bien vu !
Après avoir passé pas mal de temps à regarder les logs système, je n'ai regardé les logs apache que cette après-midi... je ne pensais pas que le souci pouvait venir de là, cf. :

Faut-il incriminer ces saletés de robots ? Pour quelle raison se mettraient-ils subitement à lancer plus de requêtes en parallèle ? Est-ce que chatgpt pourrait être le responsable ? (je ne l'avais pas vu passer dans les logs, jusqu'à présent...)

Le truc inédit, c'est l'ampleur de "l'attaque", parce que oui, à ce niveau là ça ressemble presque à une attaque DDoS...

Une attaque des Apaches venue de Chine, quelle ruse de Sioux

[Mathias]

Une attaque des Apaches venus de Chine, quelle ruse de Sioux

Alors, non, pour le coup, apache c'est le gentil dans l'histoire : c'est lui qui t'envoie les pages Kikouroù... et c'est lui qui se fait attaquer par des chinois (et dans une moindre mesure par chatgpt, qui n'est pas non plus inoffensif AMHA).