Lenteur chargement page

Plugins Protocole domotique
1

Bonjour,

Je voudrais juste savoir si je suis le seul à avoir des lenteurs lorsque j’essaye d’accéder à la page du plugin RFXCom (DOMContentLoaded: 56,21 s, load: 56,40 s). Une fois chargée, tout fonctionne correctement, le chargement des modules, les actions… mais si je reviens sur la page avec F5 ou en cliquant sur Protocole domotique > RFXCom, c’est rebelote. Aucun problème avant la mise à jour et le démon se lance sans souci de mon côté :

[2020-12-01 09:56:42][INFO] : Start rfxcomd
[2020-12-01 09:56:42][INFO] : Log level : info
[2020-12-01 09:56:42][INFO] : Socket port : 55000
[2020-12-01 09:56:42][INFO] : Socket host : 127.0.0.1
[2020-12-01 09:56:42][INFO] : PID file : /tmp/jeedom/rfxcom/deamon.pid
[2020-12-01 09:56:42][INFO] : Device : /dev/ttyUSB0
[2020-12-01 09:56:42][INFO] : Apikey : ****
[2020-12-01 09:56:42][INFO] : Callback : http://127.0.0.1:80/jeedom/plugins/rfxcom/core/php/jeeRfxcom.php
[2020-12-01 09:56:42][INFO] : Cycle : 0.3
[2020-12-01 09:56:42][INFO] : Serial rate : 38400
[2020-12-01 09:56:42][INFO] : Serial timeout : 9
[2020-12-01 09:56:42][INFO] : Protocol : 5,6,12,13,18,20,21,22,23
[2020-12-01 09:56:42][INFO] : Find device : /dev/ttyUSB0

Je demande juste un retour d’expérience, pas forcément de l’aide, car si je suis un cas isolé, je chercherais l’origine du problème moi-même :wink:

2

Casi instantané chez moi

3

Slt …
Voir surcharge de l’environnement …
Accès directement en Local ?
Comme dit notre ami

4

Pas de soucis de surcharge, le rfxcom est seul sur un raspberry. Dès lors que je charge la page, le cpu du php monte à 100%. J’ai regardé un peu ce qu’il fait et ça boucle sur des accès en lecture on dirait :

lstat64("/var/www/html/plugins/rfxcom/core/config/devices/0x40/0x71.{jpg,png}", 0x7ed94f18) = -1 ENOENT (No such file or directory)
readlink("/var/www/html/plugins/rfxcom/core/config/devices/0x40/0x71.{jpg,png}", 0x7ed9a0dc, 4095) = -1 ENOENT (No such file or directory)
lstat64("/var/www/html/plugins/rfxcom/core/config/devices/0x40", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/var/www/html/plugins/rfxcom/core/config/devices", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/var/www/html/plugins/rfxcom/core/config", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/var/www/html/plugins/rfxcom/core", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/var/www/html/plugins/rfxcom", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/var/www/html/plugins", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64("/var/www/html", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64("/var/www", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/var/www", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("./0x71.{jpg,png}", 0x7ed9aae8) = -1 ENOENT (No such file or directory)
...

Et j’ai ces lignes pendant un certains temps, après ça revient à la normale.

PS : J’ai que 20 équipements et 3 types de produit, mais pas de 0x71…

5

Bon j’ai trouvé le problème, la fonction getImgFilePath est trop gourmande, elle est appelée 4 fois par le fichier desktop/php/rfxcom.php, à voir @Loic si tu considères comme un bug ou un hardware non adapté de mon côté pour charger juste 4 images. En attendant, j’ai supprimé la fonction et mis en dur le chemin vers les images des devices.

6

J’ai fait une optimisation en beta a voir si ca suffit mais la je vois pas comment faire mieux… Je pense ya un soucis autre chez toi car la je vois pas pk il remonte partout il devrait rester dans /var/www/html/plugins/rfxcom/core/config/devices

7

Tu as mis dans une variable les appels ? Il y avait du mieux mais ce n’est pas encore un résultat satisfaisant.

Ce que je ne comprends pas c’est pourquoi il tente de lire un fichier 0x71.{jpg,png} dans le dossier 0x40… Les appels systèmes sur les dossiers sont normaux je pense, c’est du strace.

J’ai remarqué le même comportement dans le plugin OpenZwave, les images étaient longue à charger… Pas de problème pour le plugin Philips Hue. Du coup j’ai regardé les points communs et le problème vient peut-être de la fonction ls du core que se partage RFxcom et OpenZwave. Y a déjà un bug je crois au niveau de:

$deep_items = ls($pattern, $this_folder, $recursivly, $options); # :RECURSION:
devrait être $deep_items = ls($this_folder, $pattern, $recursivly, $options); # :RECURSION: ????

bon ce n’est pas mon problème mais je tenais à le signaler. Je n’ai rien vu d’autres de louche, j’ai la flemme de décortiquer le code.

Je vais subir ces temps de chargement en attendant mieux, ce n’est pas critique vu que l’essentiel fonctionne et que la majorité des gens sont sur du SSD^^

8

Effectivement la fonction avait un soucis je viens de pousser la correction si tu es en v4 tu as juste a forcer une maj meme si il ne te dis pas qu’il y en a une

9

L’usage de la fonction ls est trop gourmande pour moi car pour chaque module, il parcourt l’ensemble des dossiers à chaque fois, plus il y a de dossiers et plus c’est du travail. Pour améliorer les choses, on devrait parcourir qu’une fois le dossier de base puis mettre tout ça dans un tableau, ça évite des IO pour rien. Sinon dans les cas simple comme ici on peut directement parcourir le dossier de destination contenant l’image. C’est valable pour ce plugin, ainsi que les autres comme OpenZwave, il y a clairement une amélioration à faire la dessus.

Je vais en arrêter là vu que le problème a été identifié, et pour ceux qui sont intéressés et qui ont comme moi des soucis de chargement, voici ma modif temporaire à faire dans le fichier rfxcom.class.php :

        public static function getImgFilePath($_device) {
                foreach (ls(dirname(__FILE__) . '/../config/devices', explode('_', $_device)[0], false, array('folders', 'quiet')) as $folder) {
                        foreach (ls(dirname(__FILE__) . '/../config/devices/' . $folder, $_device . '.{jpg,png}', false, array('files', 'quiet')) as $file) {
                                return $folder . $file;
                        }
                }
                return false;
        }
10

N’hesite pas a proposer une correction mais la honnetement j’ai pas le temps de me pencher la dessus j’ai deja passer trop de temps dessus…

Surtout que la on parcours au pire une centaine de dossier et dès qu’on trouve on s’arrete. Mais je vais prendre ta modification qui marche pour le plugin rfxcom (mais malheureusement pas forcement pour les autres plugins ou on connait pas le nom du dossier a l’avance et ou celui-ci peut changer dans le temps)

11

J’ai 9 modules oregon 0x52, 26e dossier, donc on parcourrait inutilement 225 dossiers (9 * 25) fois. Et comme la méthode était appelée 4 fois, ça fait 900 dossiers rien que pour ce module. On peut comprendre ma réaction, je ne cherche pas la petite bête, j’ai des raspberry sans SSD, autant les utiliser dans une architecture décentralisée.

En tout cas, merci de la prise en compte de ma modification, il y aura forcément des heureux :smiley:

Et j’ai modifié aussi OpenZwave, lui il est plus simple, je gagne un peu près 20s de ma vie :

        public function getImgFilePath() {
                ...
                foreach (ls(dirname(__FILE__) . '/../config/devices', '*_'.$this->getConfiguration('manufacturer_id'), false, array('folders', 'quiet')) as $folder) {
                        ...
                return false;
        }
2 « J'aime »
12

Effectivement c’est mieux aussi et j’ai jamais dit que tu cherchais la betite beta au contraire. Juste que la je suis a bout et sous l’eau et je doit arreter de prendre des points c’est plus possible.