Grosses lenteurs de toute l'interface après passage en alpha version après le 07/05/2024

[TiTidom]

Bonjour à tous,

J’ai un soucis mon capitaine

J’ai plusieurs Jeedom dont je me sers pour valider mes devs, qui sont en version alpha.

Jusque là je tournais en alpha 4.4.7 datée du 07/05/2024 :

D’habitude, je met à jour régulièrement ces alpha, et cela se passe très bien, mais depuis cette date-là, impossible d’avoir une version utilisable dès que je met à jour : énormes lenteurs dès que je met à jour, n’importe quelle page met plusieurs dizaines de secondes à se charger

Alors sur Jeedom, je veux bien, mais sur 3 jeedom différents (dont 2 sur Debian 11 et le 3ème en Debian 12) avec les 3 les mêmes symptômes, je me dit qu’il y a quelque chose !

Ce n’est pas spécifique à la dernière version alpha, car j’ai essayé il y a 3 semaines cela faisait déjà la même chose , la semaine dernière pareil… Dès que je dépasse la version que j’avais mise à jour le 07/05/2024 à 17h36m12 cela me fait pareil.

Symptôme : TOUT est lent, le moindre clic et j’ai la roue qui tourne :

puis 20 secondes plus tard :

puis encore 20 secondes plus tard (à la louche), ca finit par se charger…

Au final, pas de message d’erreur dans la page dev de Chrome, tout fonctionne bien, mais cela met une plombe à s’afficher, comme si un script tournait en boucle et bloquait le chargement de toutes les pages.

Voici la page santé (lorsqu’elle finit par s’afficher) :

Dans les logs, il n’y a rien de particulier (http.error vide par exemple)

Des exemples de temps de passage d’une page à une autre :

Page logs vers page d’accueil (en cliquant sur le logo jeedom en haut à gauche) : 19 secondes
Page accueil vers menu Réglages / système / Centre de mises à jour : 1 min 50 sec (!!).

Et pas d’usage du CPU pendant ce laps de temps, la VM ne bronche pas et est à peine entre 0 et 1% de charge, et rien de particulier dans htop à ce moment là.

J’ai tenté de vider totalement le cache, j’ai redémarré ces 3 jeedom, j’ai vérifié ils sont à jour côté OS (à la fois ceux en Debian 11 et celui en Debian 12).

Et si je restaure une sauvegarde faite juste avant la mise à jour, tout repart nickel, plus rien de rame et tout fonctionne rapidement et sans aucun soucis.

---

Alors si vous avez une idée, je suis preneur !
Et si besoin de tests complémentaire, j’ai laissé un des jeedom dans cet état, donc à disposition pour fournir toute information qui pourrait aider.

TiTidom.

[TiTidom]

Re,

Bon… sur un 4ème Jeedom (qui me sert juste de test « de zéro » d’install de mes plugins avant diffusion (donc il n’y a par définition rien dessus, aucun plugin) : je l’ai passé en alpha (il était en stable 4.3.22) et mis à jour vers la dernière alpha.

Aucun soucis : il fonctionne bien (tant mieux pour Jeedom, mais tant pis pour moi, car je ne comprend pas ce qu’il s’est passé avec mes autres Jeedom de tests ).

J’ai commencé à réinstaller dessus les plugins qu’il y avait sur les autres Jeedom (ceux qui sont lents) = nada (dans le sens, pour l’instant, tout continue à bien fonctionner).

Je vais prendre le temps de réinstaller l’un de ceux qui sont lents de zéro pour y remettre la dernière alpha et ensuite restaurer un backup, voir ce que ca donne.

Mais ca reste bizarre que cela soit arrivé sur 3 jeedom différents quand même.

TiTidom.

[Loic]

Bonjour
Regarde les issue sur le Github j’en ai ouvert et documenté une avec le même genre de symptômes mais n’ayant pas de retour des utilisateurs je n’ai pas pu avancer plus.

[TiTidom]

Bonjour Loic,

Merci pour ta réponse.

Tu parles de cete issue ? : [BUG] Issue with long polling and page refresh that hanging browser · Issue #2650 · jeedom/core · GitHub

TiTidom.

[Loic]

Oui celui la

[TiTidom]

Bon bah tu as mis le doigt sur quelque chose !!

Après avoir mis en commentaire le ajax::sucess(…) dans le fichier event.ajax.php, j’ai retrouvé un jeedom qui fonctionne à une vitesse normale.

if (init('action') == 'changes') {
		sleep(1);
		ajax::success();
		// ajax::success(event::changes(init('datetime', 0), 59));
	}

Et dans les DevTools / onglet Network, je me retrouve avec des dizaines de event.ajax.php qui ont une durée de celui du sleep mis dans le code :

J’ai mis un commentaire en ce sens dans l’issue sur le github, si tu as besoin que je fasse des tests, sur ce jeedom, je le garde en l’état en attendant…

TiTidom.

[Loic]

Ok merci j’aimerais surtout comprendre pourquoi sur certain jeedom ça bloque et pas sur d’autre….

[TiTidom]

Re,

Alors des tests que j’ai pu mener, (car je suis comme toi j’aimerais bien comprendre le pourquoi du comment), je ne sais pas si cela a son importance, mais :

• Si (depuis mon réseau local) je me connecte sur ce Jeedom « lent » via son adresse IP et sur le port 80, le Jeedom fonctionne normalement sans aucun ralentissements, le passage d’une page à une autre est fluide, la page de mises à jour s’affiche en qq secondes, la page santé également, et les event sont bien traités, mais ne restent plus en « pending » pendant une plombe dans les outils de dev de Chrome.

• Si je me connecte à ce jeedom sur le port https (j’ai modifié le port chez moi, il n’est pas en 443) mais avec son adresse IP, j’ai (bien sûr) une alerte de sécurité, mais ensuite le Jeedom est fluide, toutes les pages fonctionnelles et rapides.

• Si je me connecte à mon Jeedom (toujours depuis la même machine, sur mon réseau local) via son nom dns (https://monjeedom.monsuperdomaine.net:12345/ ) alors là les ennuis commencent et c’est lent à mourir (plusieurs secondes voires dizaines de secondes et des « fetch » dans la console dev en « pending »

Bonne fin de journée,
TiTidom.

[TiTidom]

Bonsoir,

@Loic : j’ai réussi à reproduire !

En fait, cela vient de l’IPv6 !

Sur mon réseau local, mes jeedom (et tout mon réseau de manière générale) sont déclarés sur le dns (interne) à la fois en IPv4 et en IPv6, mais le Jeedom UAT (celui qui est en v4.4.8 et qui n’est pas ralenti) ne l’était pas, car je m’en servais moins, du coup il n’avait dans le DNS qu’une entrée en IPv4.

J’ai ajouté l’entrée IPv6 de ce jeedom UAT dans mon DNS interne, j’ai flushé le dns sur mon ordinateur et sur le jeedom, et là : jeedom UAT au ralenti, il rame méchamment !

Je retire l’entrée IPv6 pour ce Jeedom UAT de mon DNS, je flush à nouveau les DNS, et je me reconnecte à l’interface jeedom = plus de ralentissement !

J’ai viré les entrées IPv6 de l’autre Jeedom mais comme là c’est sur un dns publique, j’attend que la mise à jour soit confirmée, et je retesterai également sur le 2ème.

Cela expliquerait pourquoi j’avais le soucis sur 3 jeedom mais pas le 4ème, les 3 premiers sont enregistrés en IPv4 et IPv6, mais pas le dernier.

Je reviendrai donner des nouvelles d’ici 1h, le temps que les DNS se propagent.

TiTidom.

[TiTidom]

Re-Bonsoir,

C’est confirmé, maintenant qu’il n’y a plus d’entrées DNS IPv6 pour mes 4 jeedom de tests, ils sont tous les 4 fonctionnels en v4.4.8 alpha

Maintenant, reste à trouver pourquoi cela fonctionnait jusque là en IPv6 (car ce n’est pas nouveau pour ma part l’IPv6) et plus depuis quelques semaines et en tout cas avec les dernières version v4.4.7/8.

A disposition pour échanger sur le sujet,

Bonne soirée,
TiTidom.

[Loic]

Bien joué d’heure testerais demain mais ça pourrais coller effectivement. Par contre là où c’est bizarre c’est que lors de mes tests je tapais l’ip en v4

[TiTidom]

Bonjour,

Pour clore ce sujet : suite au patch trouvé et poussé par @Loic hier sur le « close session », j’ai pu remettre en place la partie IPv6 pour l’ensemble des mes jeedom (qui tournent en alpha), et qui continuent à répondre normalement et même rapidement

Merci @Loic pour avoir trouvé et pour ta réactivité !

Bonne journée,
TiTidom.