FHEM - Entwicklung > FHEM Development

Blocking functions: BlockingCall, SubProcess, CoProcess, HttpUtils_NonblockingGe

(1/5) > >>

KölnSolar:
Hallo Ihr Lieben,
immer wieder haben wir ja wegen den unterschiedlichsten Modulen Anfragen zu Latenzen/freezes. Ich hab das Gefühl(und es wird dank Cloud  >:( :'( immer mehr), dass von der wachsenden(das ist prima) Entwicklerzahl mehr Wert auf Funktion als Performance gelegt wird. Funktion heißt dabei oft lediglich: Informationen periodisch(internaltimer) aus "fremden" Datenquellen(files, Cloud, irgendwelche nodejs/python Anwendungen....) zu beschaffen. Ich bin der Auffassung, dass diese Informationsbeschaffung nichts im Hauptprozess von FHEM zu suchen hat, da dieser dadurch ausgebremst wird und die meines Erachtens primäre FHEM-Funktion der event-Steuerung und Schaltzentrale nicht mehr quasi realtime erfolgt. Mal mehr, mal weniger. :'(

Ich kümmere mich um eins dieser bösen Module. Ein Read eines files dauert leider ca. 1 Sek. und vermutlich lässt sich daran nichts ändern. In meiner Installation werden 27 Reads/min. ausgeführt. Das war natürlich unbefriedigend bzgl. Latenzen/freezes/performance. Also habe ich(unwissend zu möglichen Nebenwirkungen) BlockingCall eingesetzt. Grundsätzlich war das Ergebnis mehr als zufriedenstellend. Nebenwirkungen hatte ich auch keine. Nun lese ich aber immer wieder, dass BlockingCall den Hauptprozess im Speicher kopiert und es deshalb zu Problemen kommen kann. Andre hat SubProcess und CoProcess als Alternative in den Raum gestellt, die zumindest die Speicherproblematik etwas mehr eingrenzen sollten. Viel findet man zu diesen Funktionen nicht und eine Test-Implementierung scheint mir auch nicht auf die Schnelle machbar.

Nun meine Fragen/Diskussionspunkte:
1. Wer weiß etwas mehr über die genannten Funktionen und kann Infos über Einsatzzweck, Nebenwirkungen, Beispiele, Unterschiede sagen/verlinken ?
2. Seht Ihr es nicht auch so, dass die periodisch pullenden Informationsbeschaffer-Funktionen GRUNDSÄTZLICH ausgelagert gehören und dass wir dazu einen "Entwicklungsleitfaden" haben sollten ?
(3. Ich beobachte erstmalig meinen Speicherverbrauch. FHEM: 340MB(seit 27 Tg.), alexa: 160MB, npm: 127MB, Python: 226MB, 83MB pi-hole.
     Ich erkenne da jetzt nicht das Problem, das gg. BlockingCall spricht. Eher gg. alexa,npm,Python...[bei einer komplexen Anwendung wie alexa oder zigbeemqtt ist mir die Notwendigkeit sehr wohl bewusst;Bei Kleinigkeiten frage ich mich aber immer, warum nicht versucht wird externe open-source in Perl zu übersetzen])


Danke&Grüße
Markus

Dr. Boris Neubert:
Hallo,

zu SubProcess gibt es in contrib eine Beispielimplementierung.

Viele Grüße
Boris

Wzut:

--- Zitat von: KölnSolar am 08 Januar 2020, 10:22:17 ---1. Wer weiß etwas mehr über die genannten Funktionen und kann Infos über Einsatzzweck, Nebenwirkungen, Beispiele, Unterschiede sagen/verlinken ?
2. Seht Ihr es nicht auch so, dass die periodisch pullenden Informationsbeschaffer-Funktionen GRUNDSÄTZLICH ausgelagert gehören und dass wir dazu einen
--- Ende Zitat ---
1. ich verwende in einigen meiner Module BlockingCall. Child erzeugen, Daten holen & verarbeiten, Child sterben lassen. IMHO elegant, das Thema Speicherverbrauch kam hier vermutlich zu Unrecht in die Diskussion und hat sich ja inzwischen mit den neuen HTTPMod Version erledigt.
Ich verwende BC aber in zwei meiner Module (MPD & SIP) auch als Dauerläufer, da jederzeit von externen Quellen Daten anfallen können und ich die sofort an den Eltern Prozess durchreichen muß. Hier wäre eventuell eine andere Lösung (die ich allerdings nicht habe ) angebrachter.

2. Zustimmung, aber https://wiki.fhem.de/wiki/Blocking_Call reicht doch jetzt aus ? Es sei denn es gäbe Alternativen

zap:
Ich bevorzuge SubProcess. Allerdings ist das eher für Dauerläufer im Hintergrund geeignet als für einmalige Aktionen, die FHEM nicht blockieren sollen. Dafür würde ich auch Blockingcall verwenden.

KölnSolar:
Hm, viel ist ja nicht zusammengekommen.  :'(

zu
--- Zitat ---1. Wer weiß etwas mehr über die genannten Funktionen und kann Infos über Einsatzzweck, Nebenwirkungen, Beispiele, Unterschiede sagen/verlinken ?
--- Ende Zitat ---
eigentlich nichts.
zu
--- Zitat ---2. Seht Ihr es nicht auch so, dass die periodisch pullenden Informationsbeschaffer-Funktionen GRUNDSÄTZLICH ausgelagert gehören und dass wir dazu einen "Entwicklungsleitfaden" haben sollten ?
--- Ende Zitat ---
eher Zustimmung, aber bei einer Rückmeldung und noch nicht einmal ein Daumen hoch....  :-\

@Wzut: Kannst Du das
--- Zitat ---Speicherverbrauch kam hier vermutlich zu Unrecht in die Diskussion und hat sich ja inzwischen mit den neuen HTTPMod Version erledigt.
--- Ende Zitat ---
noch etwas näher ausführen, weil mir das als Gegenargument immer wieder entgegenkommt. Beobachten kann ich bei mir keine Probleme. Im Gegenteil: BlockingCall macht was es soll und der Hauptprocess schnurrt durch.

Und noch ein Beispiel zu meinem Wunsch zu 2. Um bei PV-Anlagen den tatsächlichen Verbrauch zu ermitteln benötigt es 2 devices. Wenn nun ein größerer(> 0,5s) Zeitraum zwischen der Abfrage der devices liegt, gibt es keine sinnvollen Werte mehr. Funkt ein "Langläufer" dazwischen, war es das.

Und noch etwas zur Klarstellung wonach ich suche: BlockingCall wird ja vermutlich deshalb kritisch wg. Speicherverbrauch beäugt, weil es eine Kopie des Hauptprozesses bereit stellt. Ich vermute, dass das notwendig ist, um eben auf sämtliche Daten aus FHEM zugreifen zu können. Ich suche aber etwas, wo FHEM gar keine(eine geringe) Rolle spielt. Ansonsten ähnlich der Arbeit mit BlockingCall.
Start mit Funktionsparametern-->Lesezugriffe(HTTP,File,DB,externe Softwareprozesse....) -> ggfs. Filterung u. rechenintensive Umrechnungen -> Rückgabe Daten an den Hauptprozess-> Beenden des Teilprozesses
Alternativ: Start eines "Nebenprozesses" mit einem define und Beendigung mit einem undefine; der "Nebenprozess" versorgt den Hauptprozess zyklisch mit Daten(dafür sind als Lösung SubProcess und CoProcess geeignet ?  :-\)

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln