Diskussion zum Thema Systemlast bei Events und attr event-on*

[CoolTux]

Guten Morgen,

Ich habe Rudi auf Basis einer bereits geführten Diskussion im Forum heute Morgen eine Mail geschrieben um meine Neugier zu befriedigen. Zu Recht wies mich Rudi darauf hin das solch eine Frage/Diskussion doch besser im Forum für die Allgemeinheit geführt werden sollte.
Hier meine Mail

Code Auswählen Erweitern


Guten Morgen Rudi,

Mir hat unsere gestrige Unterhaltung keine Ruhe gelassen, und weil ich immer gern viel wissen möchte frage ich einfach mal.
Gibt es eine generelle/grundlegenden Haltung/Beobachtung zum Thema Systembelastung und Events oder Systembelastung und event-on* ?

Habe bisschen die Nacht drüber nachgedacht. Gerade aus dem Blick eines Users.
Was denkst Du verursacht in einer FHEM installation mit rund 500 Devices mehr Last. Alle Events durchrauschen zu lassen oder mit event-on* zu filtern?

Als Entwickler kann man sich einen Überblick verschaffen welche Module in welchen Maße Events erzeugen. Als User kann man es wenn nur beobachten. Beispiel.

Yahoo Wetter:
Das Modul erzeugt in einem Rutsch eine Flut von Events. Generell die meisten Module welche Daten pollen erzeugen in einem Rutsch einen haufen von Events.

Konntest Du aus persönlicher Sicht da bereits Erfahrungen machen was nun besser ist oder macht es am Ende eher die gesunde Mischung aus Events zulassen und bedingten event-on*



Grüße


Wie denkt Ihr darüber oder habt Ihr Erfahrungen machen können. Wie gesagt ich habe vor 2 Jahren mit einem RaspiB+ angefangen und da bin ich gefühlt schnell an die Granze gekommen. Alles stockte und hinkte. Nach dem ich dann alle Devices irgendwie Sinnvoll mit event-on* versehen hatte ging es wieder gefühlt flüssiger voran.



Grüße
Leon

[rudolfkoenig]

Was denkst Du verursacht in einer FHEM installation mit rund 500 Devices mehr Last.
Alle Events durchrauschen zu lassen oder mit event-on* zu filtern?

Haengt davon ab
- wieviele Events generiert jeder diese Geraete, und braucht man diese?
- wieviele Verbraucher (notify/FileLog/etc) gibt es, und wieviele haben davon ein NOTIFYDEV
- was machen die Verbraucher mit den Daten (Datei schreiben, Versenden, Flag im Speicher setzen, nichts)

Als Modulautor wuerde ich darauf achten, dass ich nur dafuer Events generiere, was "normale" Benutzer verwenden wollen.
Falls Events fuer debugging oder fuer Sonderfaelle gibt, dann diese im Modul per eigenes Attribut freischalten lassen, damit "normale" Benutzer nicht vom Muell genervt sind. Sollte aber ein Sonderfall sein.

event-on-* hat Nachteile:
- genau zu setzen ist aufwendig
- FHEMWEB oder eventTypes verlieren an Funktionalitaet (eventTypes braucht man fuer die FileLog/notify/etc Wizards)
- wenn man spaeter ein per event-* gefiltertes Event braucht, darf man nicht verdraengen, dass man es gefiltert hat.

Alles in allem ist das Problem nicht so schlimm: ich hatte letztens Performance-Probleme in einer Installation mit 560 HM-Geraeten + 650 Notifies auf einem Cubie gemeldet bekommen: schuld war aber nicht die generelle Architektur, sondern ein HM-Bug, bei dem ein "global notify" fuer alle HM-Geraete aktiviert war.

[CoolTux]

Hallo Rudi,

Vielen Dank für Dein Statement. Schaut so aus als wenn ich in meiner ICH-Überlegung, zu viel negatives reininterpretiert habe 



Grüße

[Dr. Boris Neubert]

Hallo,

noch ein (generischer) Beitrag von mir.

Angenommen,
- es geht darum, die beiden Alternativen mit/ohne event-on-*-Filterung gegeneinander abzuwägen,
- man hat eine Testumgebung, wo die Auswirkungen erprobbar sind,
- Systemlast wird über die total konsumierte CPU-Zeit pro Laufzeit (was die Uhr an der Wand zeigt) gemessen,

dann könntest Du nytprof zum Profilieren verwenden, um zu sehen, wo der Aufwand anfällt, ob Methodenwechsel nur den Aufwand verlagert oder auch reduziert.

Ich komme darauf, weil ich mich gerade mit der Laufzeit des Calendar-Moduls bei großen Kalendern auseinandersetze und nytprof einsetze. In diesem Anwendungsfall sind die o.g. Bedingungen erfüllt.

Grüße
Boris

[Thorsten Pferdekaemper]

Hi,
ich kann bestätigen, dass nytprof wirklich nützlich ist. Ich habe es verwendet, um ein paar üble CPU-Fresser aus dem HM485-Modul rauszubekommen.
Gruß,
   Thorsten

[CoolTux]

Hallo,

Vielen Dank Boris für Deinen hilfreichen Beitrag. Habe mich mal eben kurz durch den aktuellen Kalenderthread gewälzt. Wirklich sehr interessant. Auch der Wikiartikel ist sicherlich einen Blick wert. Ich werde mir mal mein System im Bezug auf CPU Fresser etwas genauer anschauen. Schadet ja nie mehr zu wissen.

Thorsten, ich Danke Dir für Deine Bestätigung.



Grüße