Mise à jour V4.035 - 03-03-2015

[Lionel57]

Certes, mais quand je vois 8s chez Nico pour un getRoomName, plus de 6 secondes pour bien d'autres choses, je m'interroge grandement. C'est certains, je ne subis pas ce genre de lenteur. Et je parle bien des scènes, des scènes complexes, qui mèle du LUA de la HC2, qui exécute du PHP, des appli Android où je retrouve instantanément le résultat sur la HC2. 

 

En bref, je ne pense pas que c'est la V4 qui est en cause, mais peut être la conversion de la V3 à  la V4 (comme dit avant, j'étais en V4 béta, dès l'inclusion du premier module, ce qui explique peut être bien des choses)

[Krikroff]

Dans une scène V4.035 "stable" HC2 Version 1 (>300 devices, >30 scènes, >80 nodes)

[DEBUG] 23:34:07: Nb runs : 1000 | id : 7 | G.Variable : test
[DEBUG] 23:34:07: ----------------------------------------------
[DEBUG] 23:34:07:
[DEBUG] 23:34:13: getValue Exist : instruction time : 6s | cpu time : 3.56s
[DEBUG] 23:34:18: getValue Not Exist : instruction time : 5s | cpu time : 3.24s
[DEBUG] 23:34:38: setValue : instruction time : 20s | cpu time : 7.4s
[DEBUG] 23:34:43: getGlobal Exist : instruction time : 5s | cpu time : 3.93s
[DEBUG] 23:34:49: getGlobal Not Exist : instruction time : 6s | cpu time : 3.25s
[DEBUG] 23:35:59: setGlobal : instruction time : 70s | cpu time : 8.81s
[DEBUG] 23:36:22: getType : instruction time : 23s | cpu time : 17.71s
[DEBUG] 23:36:43: getName : instruction time : 21s | cpu time : 16.61s
[DEBUG] 23:37:03: getRoomID : instruction time : 20s | cpu time : 16.21s
[DEBUG] 23:37:31: getRoomName : instruction time : 28s | cpu time : 21.27s
[DEBUG] 23:37:36: getSunrise : instruction time : 5s | cpu time : 3.56s
[DEBUG] 23:37:36:
[DEBUG] 23:37:36: ----------------------------------------------
[DEBUG] 23:37:36: ALL DONE 

Dans une scène en V4.024 HC2 Version 2 (juste quelques modules, VD, Plugins (perso))

[DEBUG] 23:44:07: Nb runs : 1000 | id : 50 | G.Variable : test
[DEBUG] 23:44:07: ----------------------------------------------
[DEBUG] 23:44:07:
[DEBUG] 23:44:09: getValue Exist : instruction time : 2s | cpu time : 1.38s
[DEBUG] 23:44:11: getValue Not Exist : instruction time : 2s | cpu time : 1.28s
[DEBUG] 23:44:21: setValue : instruction time : 10s | cpu time : 2.94s
[DEBUG] 23:44:23: getGlobal Exist : instruction time : 2s | cpu time : 1.46s
[DEBUG] 23:44:25: getGlobal Not Exist : instruction time : 2s | cpu time : 1.22s
[DEBUG] 23:45:08: setGlobal : instruction time : 43s | cpu time : 3.32s
[DEBUG] 23:45:14: getType : instruction time : 6s | cpu time : 4.52s
[DEBUG] 23:45:20: getName : instruction time : 6s | cpu time : 4.52s
[DEBUG] 23:45:25: getRoomID : instruction time : 5s | cpu time : 4.57s
[DEBUG] 23:45:33: getRoomName : instruction time : 8s | cpu time : 6.21s
[DEBUG] 23:45:35: getSunrise : instruction time : 2s | cpu time : 1.32s
[DEBUG] 23:45:35:
[DEBUG] 23:45:35: ----------------------------------------------
[DEBUG] 23:45:35: ALL DONE 

Dans un module virtuel en V4.0XX HC2 Version 1 & 2

[DEBUG] 23:52:03: Nb runs : 1000 | id : 50 | G.Variable : test
[DEBUG] 23:52:03: ----------------------------------------------
[DEBUG] 23:52:03:
[DEBUG] 23:52:03: getValue Exist : instruction time : 0s | cpu time : 0.04s
[DEBUG] 23:52:03: getValue Not Exist : instruction time : 0s | cpu time : 0.04s
[DEBUG] 23:52:10: setValue : instruction time : 7s | cpu time : 0.58s
[DEBUG] 23:52:10: getGlobal Exist : instruction time : 0s | cpu time : 0.03s
[DEBUG] 23:52:10: getGlobal Not Exist : instruction time : 0s | cpu time : 0.03s
[DEBUG] 23:52:10: setGlobal : instruction time : 0s | cpu time : 0.08s
[DEBUG] 23:52:10: getType : instruction time : 0s | cpu time : 0.02s
[DEBUG] 23:52:10: getName : instruction time : 0s | cpu time : 0.03s
[DEBUG] 23:52:10: getRoomID : instruction time : 0s | cpu time : 0.03s
[DEBUG] 23:52:11: getRoomName : instruction time : 1s | cpu time : 0.07s
[DEBUG] 23:52:11: getSunrise : instruction time : 0s | cpu time : 0.03s
[DEBUG] 23:52:11:
[DEBUG] 23:52:11: ----------------------------------------------
[DEBUG] 23:52:11: ALL DONE 

Mon avis sur la question:

 

- Les Modules Virtuels tournent encore avec le même moteur que pour la V3, les perfs sont au rendez-vous.

- Les scènes tournent sur le nouveau moteur "scènes" et j'imagine qu'un logger est à  l'origine de ce problème de performance.

[Lazer]

Chaque module virtuel s'exécute dans un processus isolé au niveau système. Ces processus sont mono-threadés => j'ai 18 process.

 

Chaque scène s'exécute dans un thread, et tous ces thread appartiennent au processus principal de la HC2 => j'ai 59 threads !!!

 

JC, c'est quoi que tu appelles un logger ?

[Krikroff]

Pour archiver toutes les demandes dans des fichiers journaux, mais cela doit être du fait maison

[Lazer]

OK je confirme, il y a plein de choses logguées en v4, beaucoup plus qu'en v3.

 

Par contre, quand je vois la vidéo de 971jmd avec la scène qui tourne à  fond, et des cores qui ne sont pas à  100%, je me dis quand même qu'il doit y avoir une mauvaise gestion de threads qui doivent s'attendre mutuellement les uns et les autres, non ?

 

Rhhhaaa comme par hasard je n'ai plus aucune v4 chez moi pour jouer (non ma box ne passera pas en v4 de si tôt...)

 

 

Sinon, ça serait envisageable de faire tourner GEA dans un module virtuel ? Il y a des risques de plantage ?

[cocolabombe0]

Ma commande de la box est du 24/10/2014

[Krikroff]

J'ai essayé de pousser Steven du côté obscure du VD mais que nenni . Bon en même temps le nouveau moteur "scènes" apporte l'asynchronisme (non, ce n'est pas une pratique sadomazo, quoique ) et je pense que c'est une bonne piste de travail pour GEA puisque cela évite les blocages et les files d'attente. 

[Lionel57]

Un truc qui me chiffonne un peu, quand on fait un getGlobal, un getValue, un getRoom, multithread ou pas, on ne fait qu'interroger une base de données (on n'est pas dans du calcul qui sollicite àmort le proc). Et de voir que pour interroger ce qui normalement est sensé être une clé primaire (ID), qu'on passe àun rapport de 1 à7 pour le retour, il y a quand même un truc. Peut être certaines tables sont indexées, d'autres pas.

[Lazer]

Il y a encore un autre process qui gère les accès à  la DB. Donc ça fait des communications inter-process à  gérer encore....

 

Et puis la base en elle même, je ne la trouve pas super clean.... on sent bien les évolutions de versions successibles :/

[Krikroff]

C'est le problème des corrections sur corrections, a un moment il faut tout remettre à  plat !

 

@Lionel57, cela va dans le sens de l'utilisation de fichiers journaux (pour du debug) et ça bouffe un max de temps...

[Lionel57]

Oui, là , je suis d'accord et je pense que tout le problème vient de là . Et ça expliquerait pour quoi tout ceux qui viennent de la version 3 ont autant de problèmes... J'ai un peu le sentiment qu'entre les versions, ils empilent au lieu de revoir l'architecture de leur table.

 

Un exemple, pourquoi 7 fois plus longtemps pour interroger un getRooms qu'un getValue ? 

 

Autres choses, si l'ID d'une room est 5, il n'y aura pas de module avec un id à  5. Donc ça suppose une table commune pour tous les ID, mais ça suppose des requêtes 'SELECT xxx FROM (SELECT yyy FROM zzz). Et l'empilement des requêtes, ça plombe grandement les perfs de la base de données.

 

Donc en bref, j'ai l'impression que lorsqu'ils implantent une nouveauté, ils empilent au lieu de revoir l'architecture de la base

[Lazer]

Les rooms et les modules sont dans des tables différentes, donc pas besoin de requêtes imbriquées.

 

Mais ça ne veut pas dire pour autant que la table est bien optimisée, ou que les requêtes le sont.... ton impression est la bonne je pense

 

Au final, migration depuis une veille version ou réinstallation from scratch en v4, tout le monde a la même base, aux erreurs d'intégrités près....

[Lionel57]

Lors de la toute dernière beta avant leur version V4 dite 'stable', il m'est arrivé un truc bizarre. La lumière du salon et la lumière de la chambre se sont subitement retrouvées liées (quand j'actionnais l'interrupteur de la chambre, ça allumait également le salon) (juste sur la dernière béta). J'ai exclu plus ré-inclu, le problème était résolu. Mais en attendant, dans une base avec des clés primaires, comment ce genre de chose est possible ??? Forcément, ça aurait dà» faire planter la base. Donc, des index et des clés à  revoir, si toutefois elles existent.

 

En même temps, je parle dans le vide, finalement, aucune idée à  quoi ressemble leur base, mais j'avoue, vraiment, j'aimerai bien voir...

[Lionel57]

On a une machine qui est puissante, pour le peu de choses qu'on lui demande. En terme d'exécution, c'est vraiment basique, le proc est de taille démesurée par rapport aux réelles besoins. Mais une base pourrie, même avec une bête de course, ça bloque...

[Lionel57]

Ceci dit, je fais le malin, mais je sais au combien c'est complexe de faire évoluer une base de données, on a vite fait de créer des contraintes d'intégrités. Mais c'est aussi pour ça, qu'en programmation de scripts, comme pour la gestion d'une base, je préfère plusieurs petites structures, plutôt que des mastodontes (scripts ou tables), beaucoup plus risqué, beaucoup plus compliqué àfaire évoluer

[cocolabombe0]

Je ne peux plus modifier le délai entre chaque interrogation.

Avez vous pareil? Je crois l'avoir vu quelque part ou sur l'ancienne version.

[Steven]

Juste pour info, cela n'est pas un vrai benchmarkt mais juste une piste car GEA est devenu très lent.

 

J'ai, perso, l'impression qu'il n'y a plus aucune option de cache exploitée.

 

Je posterais sur le forum officiel demain pour obtenir une réponse. En tout cas, il y a pas photo, c'est devenu lent.

[Lionel57]

Quand tu dis entre chaque interrogation, tu veux dire pour un module à  pile ? As-tu réveillé ton module ? 

Avant, oui, j'avais ce souci, même après réveil, je me retrouvais avec une valeur farfelue. Mais là , je n'ai pas testé sur cette version, le problème était résolu depuis 2 ou 3 versions

[Lionel57]

@Steven, quelques part, vu le truc, ça ne m'étonne pas trop, GEA, c'est du lourd. (pas une critique, un truc de génie, mais pas un petit truc). Le Multi-thread a ses avantages, ses inconvénients. L'avantage, c'est que ça accélère grandement le process en parallèle de plusieurs applications. L'inconvénient, les appels inter-thread, c'est lent.

 

Ceci dit, je n'ai jamais analysé le truc, mais si avant, le script enchaînait de nombreux appel de fonction (supposition), ben peut être à  revoir, quitte à  bouffer de la mémoire, mais stocker dans des variables locales, ça devrait accélérer le truc. 

[971jmd]

Je cherche a comprendre

 

Question bête, pourquoi quand je réalise le test de STEVEN dans un bouton  virtuel en lua, les résultats sorte à  zéro

 

--[[
%% properties
%% globals
--]]
 
-- Parameters --
local id_exist = 274
local global_exist = "var22"
local nbIteration = 1000
 
-- Do not touch please ---
local id_not_exist = 100056
local global_not_exist = "AABBCCDDEEFFGGHHIIFF"
 
function log(name, start)
  	if (start) then
		fibaro:debug("<span style=\"font-family:monospace; white-space:pre; clear:both; float:right\">  "..name .. " " .. (os.time()-start) .. "s</span>")
	else
		fibaro:debug("<span style=\"font-family:monospace; white-space:pre; clear:both; float:right\">  "..name .. "</span>")
    end
end
 
function execute(name, func)
  if (not pcall(function() 
        local start = os.time()
        for i= 1,nbIteration do
          func()
        end
        log(name, start)
    end)) then
  	fibaro:debug("ERROR : " .. name)
  end
end  
 
log("Nb runs : " .. nbIteration .. " | id : " .. id_exist .. " | G.Variable : " .. global_exist)
log("----------------------------------------------")
log("")
 
-- Tests ---
execute("getValue Exist      :", function() fibaro:getValue(id_exist, "value") end)
execute("getValue Not Exist  :", function() fibaro:getValue(id_not_exist, "value") end)
execute("setValue            :", function() fibaro:call(id_exist, "setValue", fibaro:getValue(id_exist, "value")) end)
execute("getGlobal Exist     :", function() fibaro:getGlobalValue(global_exist) end)
execute("getGlobal Not Exist :", function() fibaro:getGlobalValue(global_not_exist) end)
execute("setGlobal           :", function() fibaro:setGlobal(global_exist, fibaro:getGlobalValue(global_exist)) end)
execute("getType             :", function() fibaro:getType(id_exist) end)
execute("getName             :", function() fibaro:getName(id_exist) end)
execute("getRoomID           :", function() fibaro:getRoomID(id_exist) end)
execute("getRoomName         :", function() fibaro:getRoomName(fibaro:getRoomID(id_exist)) end)
execute("getSunrise          :", function() fibaro:getValue(1, "sunsetHour") end)
 
log("")
log("----------------------------------------------")
log("ALL DONE")

Modifié 5 mars 2015 par 971jmd

[Lionel57]

euh, je veux bien t'aider, mais il va falloir être plus clair, quitte àmettre ton code, parce que là, je ne peux pas te répondre

[971jmd]

euh, je veux bien t'aider, mais il va falloir être plus clair, quitte à  mettre ton code, parce que là , je ne peux pas te répondre

 

j'ai modifier mon poste http://www.domotique-fibaro.fr/index.php/topic/3967-v4035-03-03-2015/?p=58047

[Lionel57]

Cette partie là, il faut que tu la modifies en mettant des ID qui correspondent àta configuration

local id_exist = 274
local global_exist = "var22"

[Lionel57]

Ooops, j'ai mal lu, visiblement, tu as fait, mais le code, il n'est pas destiné àun module virtuel, mais àune scène. Je n'ai pas analysé le code, mais le lua des scènes n'est pas tout àfait identique du lua des modules virtuels

[971jmd]

c'est à  dire, en quelque mots