Sur une page design , chaque événement eqLogic::update concernant un équipement dont la tuile n’est pas sur ce design déclenche un re-téléchargement du design complet via plan.ajax.php action byPlanHeader.
Sur notre installation : réponse de 1 567 000 octets (design de 33 tuiles), déclenchée 4,6 fois par minute en journée, soit environ 430 Mo/heure et autant de parse JSON par page design ouverte, en continu, multiplié par le nombre d’écrans (PC + tablettes murales). Aucun bénéfice fonctionnel dans 99,9 % des cas.
Mécanisme (fichiers / lignes, core 4.6.1)
Diffusion sans filtre : core/ajax/event.ajax.php sert event::changes(datetime, 59) sans
paramètre de filtre — chaque navigateur reçoit les événements de tous les équipements.
Émissions fréquentes : eqLogic->refreshWidget() est appelé par le core à chaque changement
de niveau d’alerte (cmd.class.php ~L2652), sauvegarde de commande (~L1424), statut/batterie.
Des plugins à cycle de collecte rapide (mesuré chez nous : NUT, smartthings, blitzortung)
émettent ainsi ~1 événement/minute chacun — y compris pour des équipements invisibles et posés sur aucun design.
Réaction client coûteuse : core/js/eqLogic.class.js, jeedom.eqLogic.refreshValue,
branche eqLogic == null / page == 'plan' && !jeeFrontEnd.planEditOption.state (~L528) :
la tuile étant absente du DOM, le client appelle jeedom.plan.byPlanHeader — qui renvoie l’intégralité du design (tous les objets + leur HTML) — uniquement pour vérifier si
l’équipement vient d’être ajouté au design (plans[ii].plan.link_id == result[i].id),
cas rarissime. 99,9 % du temps : aucun match, 1,5 Mo jetés.
Reproduction
Ouvrir un design en consultation ; noter un eqLogic_id X non présent sur ce design.
Observer côté client un POST core/ajax/plan.ajax.php (action byPlanHeader) dont la taille de
réponse est celle du design complet. Répété à chaque événement de ce type.
Mesures (log Apache, fenêtres de 10-11 mn comparables, pages actives)
Avant correctif : 51 réponses > 1 Mo en 11 mn (~4,6/mn).
Après correctif local (branche neutralisée) : 0 en 10 mn, avec contrôles d’activité positifs
dans la même fenêtre (57 re-rendus légitimes de tuiles présentes + 1 828 requêtes de polling) —
le zéro n’est pas dû à l’inactivité.
Correctif local appliqué (et perte assumée)
Branche remplacée par continue : les événements des tuiles absentes sont ignorés sur les designs.
Perte : une tuile ajoutée à un design depuis une autre session pendant qu’il est affiché
n’apparaît plus en direct (elle apparaît au rechargement de la page).
Pistes pour un correctif core (au choix, par coût croissant)
Supprimer la branche (notre choix) : l’apparition en direct d’une tuile nouvellement ajoutée
est un cas marginal ; le rechargement de page la couvre.
Vérification légère avant le téléchargement lourd : une action ajax renvoyant uniquement
l’existence du lien (planHeader_id, link_id) — quelques octets ; ne télécharger le design
complet que si le lien existe réellement (vrai ajout). Conserve la fonctionnalité à ~0 coût.
Plafonnement : au plus 1 vérification byPlanHeader par page toutes les N minutes.
Complément côté émission : ne pas émettre eqLogic::update pour un équipement invisible
ET lié à aucun plan/plan3d (test dans eqLogic::refreshWidget()) — économise les émissions
strictement inutiles (2 de nos 3 émetteurs à la minute étaient dans ce cas).
Défaut voisin repéré à la lecture (non mesuré)
Dans le même gestionnaire, après le bloc if (eqLogic == null) {...}, l’exécution se poursuit vers eqLogic.triggerEvent('create') (~L591) avec eqLogic potentiellement null (pages hors
dashboard/eqAnalyse/plan, ex. vues) — TypeError possible qui interromprait le traitement du lot,
même famille que le bug des templates à commentaire en premier nœud. À vérifier par l’équipe.
N’étant pas stupide , je pense comprendre, l’ensemble est d’ailleurs assez clair et facile à vérifier.
J’ajoute que tout cela (chiffres et code), ont été mis en exploitation sur mes différents sites avant d’être publié.
Maintenant pas de soucis, si ce genre de bug, particulièrement difficile à détecter et à corriger n’intéresse pas l’équipe de jeedom, il suffira de me faire cette demande en réponse à mon post et j’éviterais à l’avenir de venir ‹ polluer › ce forum et de vous importuner !.
Faut arrêter avec ça stp, ça n’a aucun intérêt à part celui de faire perdre son temps à tout le monde.
Déjà le message d’hier sur un point connu de longue date qui n’est pas vraiment problématique en soit c’était pas terrible ni sur la forme ni sur le fond à essayer de démêler les élucubrations de l’IA qui tire dans tous les sens des fois qu’elle ait juste à un endroit sur un malentendu. Il aurait été largement préférable d’expliquer quel problème concret a été rencontré et dans quelles circonstances, perso après avoir lu ce que l’IA en pensait je n’avais plus aucune envie de chercher quoi que ce soit plus loin. A nouveau, ça me semble pourtant évident mais l’équipe est en mesure d’utiliser l’IA elle même si besoin était, par contre commencer à travailler sur un sujet dont seule l’IA est à l’initiative ça n’a aucun sens !
Concernant ce sujet je ne vois pas comment tu peux affirmer que tu comprends tout alors que c’est justement totalement incompréhensible !!! L’IA a tout mélangé, ça n’a aucun sens d’autant plus qu’on a strictement aucune idée de quel est le souci à la base ! Il est encore pire que celui d’hier, s’il te plait arrêtes ça c’est totalement contre-productif, irrespectueux et c’est juste de la pollution à tous les niveaux. Si tu as un souci faut commencer par expliquer lequel déjà, ensuite éventuellement une courte analyse IA si tu veux mais pas des tartines sans fond intégralement analysées et rédigées par une IA.
PS: je pense que tu penses bien faire sans te rendre compte qu’il y en a pour plus longtemps à essayer de comprendre où l’IA veut en venir et surtout pourquoi qu’à expliquer toi même le problème de base sur lequel les développeurs pourraient se pencher. Par ailleurs tu ne semble pas te rendre compte que l’IA est très très (très) souvent à côté de la plaque surtout dans ce genre de situation.
Re-PS: concernant ce sujet je pense comprendre l’idée de fond soulevée, j’essayerais d’y regarder à l’occasion mais clairement tout ce texte IA n’incite pas à creuser plus loin. J’ai même un doute sur la réalité du souci de fond quand même : tu n’aurais pas le dashboard ouvert dans un autre onglet affichant tous les équipements dont ceux qui ne sont pas sur le design par hasard ?
Résumé
Sur une page design , chaque événement eqLogic::update concernant un équipement dont la tuile n’est pas sur ce design déclenche un re-téléchargement du design complet via plan.ajax.php action byPlanHeader.
Sur notre installation : réponse de 1 567 000 octets (design de 33 tuiles), déclenchée 4,6 fois par minute en journée, soit environ 430 Mo/heure et autant de parse JSON par page design ouverte, en continu, multiplié par le nombre d’écrans (PC + tablettes murales). Aucun bénéfice fonctionnel dans 99,9 % des cas.
était assez clair comme symptôme et comme description, il est vrai que les multiples « j’ai constaté des ralentissements dont je ne trouve pas l’origine » que l’on voit dans les comm’ sont sans doute plus gratifiant pour certain
Pour ma part, avoir enfin une solution à ce problème ‹ connu › m’arrange (idem celui d’hier, sur lequel je planchais depuis des années mais trop « pseudo-aléatoires » pour mon petit cerveau ), même si mon ego de dev aurait préféré trouver la solution tout seul dans mon coin !!!
Pour répondre à ton re-PS, je n’utilise jamais (ou exceptionnellement) le dashboard , de toute manière ma comm’ suggère qq lignes pour tester/vérifier ce prob …
Personnellement, le vrai problème que j’ai avec l’IA (comme avec mes stagiaires d’ailleurs !) c’est une tendance à prendre ses intuitions pour des certitudes au lieu de rester factuel …
Mais j’ai bien compris que à l’avenir, si je trouve avec ou sans l’aide de Mythos des solutions sur
des plantages aléatoires et peu visible et donc :
J’éviterais de venir importuner et faire perdre du temps à cette communauté !
Bien entendu que tu allais mal le prendre, c’est toujours comme ça maintenant et c’est encore pire depuis l’avènement de l’IA. Si tu veux prendre des petits bouts de mon long message explicatif rédigé manuellement alors pourquoi pas simplement :
Je sais bien que les bases évidentes d’hier ne le sont plus aujourd’hui mais rien que « se mettre à la place de son interlocuteur » par exemple, tu ne comprends pas que c’est indigeste au possible en plus d’être entièrement rédigé par IA ? Tu aimerais que dans ton taf n’importe qui arrive avec une tartine d’IA pour t’expliquer ce que tu as à à faire ? Bref, bien entendu que ce n’est pas l’IA le problème ici, j’ai pourtant essayé d’être courtois avec des explications suffisamment argumentées, je me le suis noté pour regarder à l’occaz’ mais comme pour l’autre sujet ça concerne surtout de l’optimisation finalement, il n’y a pas réellement de problème de fond.
Tu confirmes exactement ce qui est dérangeant dans ces 2 messages IA car ce souci de commentaire en début de HTML sur le design est mentionné dans de nombreux posts sur community (certes ils sont assez anciens maintenant car la réponse est présente sur plusieurs sujets j’imagine donc personne ne le lève de nouveau). Par ailleurs il n’a rien d’aléatoire, il suffit de faire commencer son code par autre chose que du HTML je maintiens que ce n’est pas vraiment problématique en soit.
OK donc on a que 2 choix c’est ça ? Soit l’analyse et un message entièrement fait par IA, soit un message générique ? T’es certain qu’y’a rien entre les 2 ? Avec l’aide de l’IA justement ? Parce qu’au final tu n’arrêtes de dire que tu as passé des années dessus pour te justifier mais on a toujours aucun élément concret. Comme déjà expliqué dans mon message précédent, je reste persuadé qu’un message de ce type serait plus pertinent :
en faisant des devs sur mon jeedom j’ai constaté tel ou tel dysfonctionnement dans telles situations (avec des cas concrets). J’ai demandé à l’IA et je me suis assuré qu’elle comprenne bien le contexte, elle pense que ça pourrait venir de…
, je pense comprendre, l’ensemble est d’ailleurs assez clair et facile à vérifier.