Performance von nonBlocking Prozessen in Abhängigkeit Hauptprozess

[JoWiemann]

Hallo,

ich habe heute ein paar Tests mit dem Modul 72_FRITZBOX.pm über die fhem.cfg.demo gemacht. Der nonBlocking Prozess zum Abholen der Daten aus der FritzBox hat über die fhem.cfg.demo nur 8 Sekunden benötigt. In meiner Fhem Installation benötigt er 22 Sekunden. Das würde ich gerne verstehen.

Danke Euch

[rudolfkoenig]

Der nonBlocking Prozess zum Abholen der Daten aus der FritzBox hat über die fhem.cfg.demo nur 8 Sekunden benötigt. In meiner Fhem Installation benötigt er 22 Sekunden.

Ich versuche zu raten, was damit gemeint ist: wenn man die Daten mit einer minimalen fhem.cfg verarbeitet, dann geht das schneller, als mit einer aufwendigen Konfiguration.

Wenn meine Uebersetzung passt: vmtl. liegt das an den Events, deren Abarbeitung in einem komplexen FHEM-Setup laenger dauert. Weiterhin laufen vmtl. auch andere Events rein die FHEM zusaetzlich bearbeiten muss. Ich gehe davon aus, dass das unterschiedliche Verhalten uabhaengig von der nonBlocking Implementierung ist.

Wenn falsch geraten: bitte mehr Details.

[JoWiemann]

Hallo Rudi,

danke für die Rückmeldung.

Im FRITZBOX Modul wird nonBlocking aus der blocking.pm benutzt. Mein Verständnis war, dass hierdurch ein komplett neuer Prozess gestartet wird. Somit sollte dieser relativ unabhängig laufen. Ich habe auf meinem produktiven RPi Fhem gestoppt und über ,,sudo perl fhem.pl fhem.cfg.demo" Fhem neu gestartet. Es liefen also zu diesem Zeitpunkt alle anderen Programme/Prozess auf dem RPi, wie sonst auch. Nach der Definition eines FRITZBOX Device konnte ich den schneller Ablauf, des regelmäßigen Prozesse der die Daten von der FritzBox holt, beobachten. Dann habe ich die Demo beendet und Fhem über die Konsole neu gestartet. Hier war dann die Laufzeit des nonBlocking Prozesses wieder fast drei mal so lang.

Grüße Jörg

[rudolfkoenig]

Ist gesichert, dass der geforkte Prozess laenger gebraucht hat und nicht das Ergebnis im Hauptprozess?
Wenn ja, dann ist im geforkten Prozess noch was unterwegs.

Eigentlich sollten alle Aktivitaeten von der Hauptschleife in fhem.pl gestartet werden, und dieser wird im geforkten Prozess nicht abgearbeitet, d.h. da sollten weder Timer noch Events eine Rolle spielen.
Aber womoeglich uebersehe ich was, und wir muessen die Ursache finden, z.Bsp. mit erhoehten verbose.
Wie ist die Auslastung der beiden Prozesse waehrend des Abholens?

In diesem Zusammenhang: je eher ein Modul forkt, desto weniger "Ballast" wird dupliziert.
Das kann man erreichen, indem man die eigene Definition nach vorne mogelt, mit $hash->{prioSave} = 1 (wird z.Zt nur von DbLog verwendet).

[JoWiemann]

Hallo Rudi,

ich werde das jetzt weiter untersuchen. Zunächst einmal danke für die Hinweise. Mal sehen, was ich rausfinden kann.

Grüße Jörg