Merci Bison pour ce retour.
Je CROIS mieux comprendre
Tu ne parles pas du temps que le scénario prends à se dérouler, mais le temps de le faire partir…!
Car tu utilises le terme « executer », qui pour moi correspond au temps que le scénario prend à se dérouler (mais pour toi c’est le temps qu’il prends à etre lancer / démarré / initier), c’est ça…?
Donc :
Je comprends que si le système à X truc a faire, à 6 h, qui prennent 10 secondes, il reste 50 secondes au système pour lancer les scénarios :
si on doit lancer 49 scénarios qui se LANCE en 1 secondes chacun, et qui DURE 10 minutes chacun, ça va.
Mais si on lance 51 scénarios qui se LANCE en 1 secondes chacun, et qui DURE 5 secondes chacun, ça va pas, car 51 eme scénario ne se lancera pas !
Donc le problème n’est pas le temps d’exécution / la durée, du scénario ! Sa durée n’a pas d’impact. Les sleeps n’ont pas d’impact.
Ce qui impact, c’est que jeedom est sous l’eau et qu’il n’a pas le temps de lancer toute ses taches !
Non c’est pas ça. Faut pas chercher si compliqué.
Un scénario synchrone, jeedom attend la fin avant de lancer le suivant, si le scenario n’a pas fini de s’exécuter ca impact les suivants.
Il est clair que sleep et synchrone sont incompatibles.
et c’est bien compréhensible
Mais pour les scénarios NON synchrones ??? … cela reste nébuleux pour moi…
(sur votre parole, je supprime actuellement les sleeps dans les scénarios ou cela est facile à faire)
Néanmoins …
Pour avoir beaucoup développé pour des systèmes temps réels-multitaches, le sleep (ou même wait d’un évènement) permet de redonner la main au scheduler qui redonne alors la main à une autre tache (la plus prioritaire à ce moment là).
Cela est-il le cas pour les scénarios non synchrones ? @Dreaky
(Rq : le sleep n’étant à priori qu’un wait dont l’événement est géré par l’horloge)
Sur le principe oui: le sleep redonne la main au cpu ici.
Mais cela veut qd meme dire qu’un process php reste actif juste pour ça (le scenario est exécuté dans son propre processus php) et ca consomme: la mémoire reste allouée, les connexions db ouvertes etc…
Un process php n’est pas fait, à mon sens, pour tourner longtemps.
De plus, à partir de 1min (ou quelques minutes) d’attente il existe d’autres techniques sous jeedom qui permettent d’éviter ça (les blocs DANS et A ou simplement déclencher sur un événement) donc pourquoi s’en priver?
Ça dépend du nombre de scénario en parallèle si y’a 150 scénario en sleep c’est un soucis. Mais si. Est 1 ou 2 en sleep sur du non synchrone pas de soucis normalement.
Comme dit la 4.5 corrigera ce soucis car jeedom si il rate le lancement a t du scénario le verra et le lancera dans la minute qui suit.
Juste pour que tu te rendes compte de combien ce sujet est éternel
(Oui, il y a une limite mais qui la touche ? Perso, j’ai jamais réussi)
Voir ce vieux poste datant de 2021 !!
Ou j’avais réaliser un test et regardé la charge Jeedom.
Qui peut dire « j’avais X sleep, ça faisait ceci
J’ai enlevé Y sleep, ça faisait cela. »
Perso jamais vu sur le forum
Le soucis c’est pas les ressources c’est les connexions à la db et il y a une limite (250 je crois) sachant que un onglet c’est déjà 2 ou 3 connexions par exemple, un démon ça en prends aussi. Chaque truc jeedom en prends.
