FHEM Forum

Hallo,

nachdem meine FHEM-Installation über die Jahre immer weiter gewachsen ist und ich deswegen auch schon mehrfach die HW (RasPi) aufgerüstet habe (vom ursprünglichen RasPi 3 auf momentan RasPi 5, 4GB) glaube ich das ich so langsam am Ende der Möglichkeiten des RasPi's angekommen bin. Speziell jetzt mit Beginn der "Sonnensaison" wo nun wieder alle meine PV-WR richtig produzieren (außer Leistung auch seeehr viele Events) steigt die CPU-Last (FHEM-Anteil) pünktlich Morgens mit Sonnenaufgang bis Abends zum Sonnenuntergang von ca. 50% auf nahezu 100%. Dabei habe ich schon versucht die Datenbelastung (Events) an mehreren Stellen einzuschränken (MQTT-Daten nur alle 2 Minuten, Event nur bei Änderung um > 15W, nur die nötigsten Daten loggen, etc.). Trotzdem komme ich kaum unter 90%.

Das führt dann manchmal dazu das Daten die zwischen dem FHEM-RasPi und dem Loxone Miniserver über UDP/HTTP ausgetauscht werden verloren gehen. Das darf natürlich nicht sein.

Ich bräuchte deshalb mal Eure Einschätzung ob ich noch was optimieren könnte, etwas grundsätzliches falsch mache, wo ich vielleicht noch nachschauen könnte oder ob der RasPi für meine große FHEM-Installation (denke zumindest das meine FHEM-Installation groß ist) tatsächlich nicht mehr ausreichend ist.

So nun zu meinem System:
HW: RasPi 5, 4GB
OS: Bookworm
SW: FHEM, pivccu3 (für homematic-Geräte)

FHEM-Devices:
  25x at
  57x di
110x dy
  10x EC3000
  17x FBDECT
396x FileLog
  17x fhempy
  28x homematic
    8x http
  14x Modbus
    7x Modbusattr
181x MQTT2-Device
131x MQTT2-Server
  98x notify
    3x OBIS
  82x readingsgroup
    1x Statistics-Device
203x SVG-Plot
    2x watchdog

Signalaustausch mit Loxone:
175x HTTP, Loxone ==> FHEM
260x UDP, FHEM ==> Loxone

Laut FHEM Event-Monitor gibt es Nachts ca. 20 Events/s und tagsüber bis zu 50 Events/s, wobei ich hier nicht wirklich weiß ob überhaupt alle Events durchkommen und im Eventmonitor angezeigt werden.



So, nun bin ich mal auf Eure Kommentare gespannt.

Ohne in die Details zu gehen wird das schwierig.

Auf den ersten Blick sieht das aber "offenkundig inneffizent" aus:
Die Zahl der FileLog ist astronomisch (DbLog?), und warum man über 100 MQTT2_SERVER benötigen sollte, erschließt sich mir nicht...
Da gibt es bestimmt noch viel mehr Ineffizienz, wenn man unter der Haube nachschaut :D .

Ich kann mir gerade nix unter
57x di
110x dy
vorstellen. Was ist das?

oh sorry dy=dummy, di =doif

@beta-user
Wieso ist die Anzahl der Filelogs astronomisch? Es gibt ja auch entsprechend viele Devices. Mit DbLog hab ich mich noch nie beschäftig. Davon habe ich keine Ahnung. Die MQTT2-Server werden doch von FHEM für jedes MQTT-Gerät automatisch angelegt. Verstehe ich da grundsätzlich was falsch?

Das mit den Ineffizienzen mag ja sein, ist sogar wahrscheinlich, aber die Hauptfrage ist ja ob ein RasPi 5 das von mir betriebene System bewältigen können sollte, oder bei dem angegebenen Umfang die Grenzen naheliegen oder nicht. Ich will auch gerne jede Info posten die notwendig ist um eine Antwort auf meine Frage zu erhalten.

OK, an temporäre MQTT2-Server-Instanzen hatte ich nicht gedacht.

Sowas besser (leider nicht perfekt) per "fheminfo" abrufen, dann steht da auch direkt "dummy".

Da der Pi nicht zu swappen scheint, ist es zumindest kein RAM-Problem.

FileLog: für jede Event-loop muss halt (wenn was zu loggen ist) das File geöffnet werden, DbLog puffert das erst mal. Dass FHEM erst mal den "einfachen" Mechanismus einrichtet, heißt ja nicht, dass das ein Muss ist.
Wie groß sind denn deine logfiles?

Letztendlich würde ich auch den Eventmonitor mal zu Rate ziehen und schauen, was und wie Event(-loop)s generiert, und wie man das ggf. reduzieren kann.
Fleißarbeit...

Wenn sich mit DbLog signifikant was in der Performance verbessern läßt, dann schaue ich mir das gerne mal an. Vielleicht ist die Umstellung ja auch ganz einfach??

Meine Logfiles sind alle als Monats-Logfiles angelegt und sind zwischen 50k und 200MB groß. Für 03-2025 sind das 302 Dateien mit zusammen ca. 2,8GB an Daten.

Optimierungs-Fleißrunden habe ich schon mehrfach gedreht, aber den richtigen Befreiungsschlag bisher noch nicht erreicht. Und eigentlich würde ich, zumindest was die ganzen Stromflüsse betrifft, lieber noch feiner aufgelöste Daten haben (also mindestens Minutenwerte).

Zitat von: Guzzi-Charlie am 13 April 2025, 13:30:27Vielleicht ist die Umstellung ja auch ganz einfach??

Na ja, du würdest in dem Fall nicht drumrum kommen, dich in die allgemeine Datenbankthematik einzulesen und einzudenken.

Zitat von: Guzzi-Charlie am 13 April 2025, 13:30:27200MB

Das kommt mir schon "ordentlich" vor. Vielleicht mal einen Blick reinwerfen, was da alles geloggt wird?

Zitat von: Guzzi-Charlie am 13 April 2025, 13:30:27Optimierungs-Fleißrunden habe ich schon mehrfach gedreht, aber den richtigen Befreiungsschlag bisher noch nicht erreicht. Und eigentlich würde ich, zumindest was die ganzen Stromflüsse betrifft, lieber noch feiner aufgelöste Daten haben (also mindestens Minutenwerte).

Bei der "Auflösung" geht es ums Loggen? DbLog kennt Filter, die dann zumindest nicht alle Events ins Log schreiben.

Ansonsten: Die Optimierung betrifft nicht nur "event-on-change-reading" &Co. passend zu setzen ;) .

Da geht es auch darum, Eventhandler sauber abzugrenzen (z.B. NOTIFYDEV bei deinen notify gesetzt?), und dann den anschließenden Code auch effektiv zu halten. Z.B. myUtils statt "on-the-fly"-Umwandlung von Code in DEF, schnelle Profung von "ist es überhaupt relevant?" usw. usf..
Es gibt hier so viele schlechte Beispiele zu finden, in denen erst alles mögliche an Variablen zugewiesen wird, berechnet und transformiert, nur um am Ende noch eine Prüfung einzubauen, die alles vorher ad absurdum führt, und die man auch direkt vorne hätte machen können. Sowas muss nicht sein und erzeugt nur unnötig Hitze im Prozessor ;) .

Zitat von: Guzzi-Charlie am 13 April 2025, 12:40:19Wieso ist die Anzahl der Filelogs astronomisch? Es gibt ja auch entsprechend viele Devices.

Ich habe gerade mal 12, selbst davon sind nur 4-5 relevant um schnell nachzuschauen und nicht eine Abfrage für die Datenbank machen zu müssen.
Man kann einstellen, ob dasAnlegen eines Logfiles Standard ist oder nicht, alternativ weglöschen, wenn das Device fertig eingerichtet und "abgenommen" ist.
Für Diagramme z.B. nutze ich die Datenbank und da kommt nur das rein was ich will.
Genauso bei Events, weniger ist immer mehr.

Zitat von: Beta-User am 13 April 2025, 16:34:33

Zitat von: Guzzi-Charlie am 13 April 2025, 13:30:27200MB

Das kommt mir schon "ordentlich" vor. Vielleicht mal einen Blick reinwerfen, was da alles geloggt wird?

Naja, das sind nur zwei und eine davon habe ich gerade weiter zusammengestutzt. Die Andere ist der Logfile einer PV-Anlage mit 7 Micro-Wechselrichtern und jeweils zwei MPP-Trackern. Die Daten hätte ich zum Regeln am liebsten noch genauer (alle 20s statt alle 2 Minuten). Die meisten liegen unter 10MB.

ZitatBei der "Auflösung" geht es ums Loggen?

Ja und event-on-change-reading, etc. (inkl. Triggerschwelle) nutze ich natürlich schon und schreibe auch nur das was ich wirklich haben möchte. Aber irgendwie scheint es für den RasPi zuviel zu sein.

ZitatDa geht es auch darum, Eventhandler sauber abzugrenzen (z.B. NOTIFYDEV bei deinen notify gesetzt?)

Bei den meisten schon, aber da kann ich ja nochmal hinschauen. Aber ich glaube nicht das es am nicht perfekten Code liegt da der Pi Nachts nur mit ca. 40-50% läuft und erst am Tag mit Erscheinen der Eventflut aus den ganzen PV-Wechselrichtern an den Anschlag läuft. Ich hab auch keine Ahnung wieviele Events ein RasPi 5 unter FHEM überhaupt verarbeiten kann. Gibt es da irgendwelche Anhaltspunkte? Es bringt ja nichts wenn ich tage- oder wochenlang versuche alles Mögliche zu optimieren (was mit auch relativ schwerfallen dürfte) um am Ende festzustellen das die HW einfach für meine Installation nicht ausreicht. Dann würde ich eher auf eine leistungsfähigere HW umziehen, obwohl es mir davor grausen würde. Dann bekomme ich sicherlich wieder viele andere Probleme.

@rabehd
Wenn Du nur 12 Logfiles hast, dann kann Deine Installation ja nicht besonders groß sein. Bei mir gibt es mehrere Hundert Aktoren/Sensoren. Hauptsächlich geht es dabei um Energieflüsse von PV, Hausverbrauch, E-Autos, Heizung, etc. und Temperaturmessungen für zwei Häuser. Für sehr viele dieser Messungen gibt es auch SVG-Plots und wenn ich mal einen neuen SVG-Plot (auch für die Vergangenheit) benötige, dann geht das eben nur wenn auch Daten vorhanden sind. Wenn die Verwendung von DbLog die Performance steigert, bzw. die Last auf dem Raspi reduzieren hilft, dann werde ich das auf jeden Fall mal ausprobieren. Bisher hatte sich mir die Frage aber nicht gestellt. Prinzipiell ist es mir doch egal wie die Daten gespeichert werden, solange es funktioniert und außerhalb von FHEM brauchte ich die Daten bisher noch nicht. Und die Umstellung ist ja auch ein nicht ganz unerheblicher Aufwand. Deshalb habe ich das bisher immer gescheut.

Falls das Hoymiles-WR sind: umstellen auf Ahoy-JSON. Details bei Bedarf.

ZitatFalls das Hoymiles-WR sind: umstellen auf Ahoy-JSON. Details bei Bedarf.

Ja, das sind Hoymiles-WR und die werden mit einer Ahoy-DTU (ESP32) abgefragt. Aber die Daten werden ja nicht weniger wenn ich eine andere Schnittstelle verwende? Das sind immerhin Daten von 24 PV-Modulen.

Ich habe 6 Hoymiles und benutze OpenDTU-OnBattery. Mein Load war mit mit MQTT2-SERVER und MQTT2-DEVICE auch zu hoch.
Habe umgestellt auf pollen mit JsonMod (http://192.168.178.35/api/livedata/status/). Sind zwar viel weniger Infos drinne,
aber die wichtigsten Leistungsdaten und etwas mehr. Per MQTT wird wirklich jeder schei* versendet, ohne das man das irgendwie
einschränken kann...

edit:
Ich sehe gerade du hast geantwortet. Ich verzichte mittlerweile auf die ganzen Infos der Module. Wenn gucke ich bei der DTU rein. Unter Fhem habe ich
meine Module auch nie kontrolliert. Setzt dir einen Weblink zur DTU.


Gruß schwatter

Zitat von: Guzzi-Charlie am 13 April 2025, 18:58:25

ZitatFalls das Hoymiles-WR sind: umstellen auf Ahoy-JSON. Details bei Bedarf.

Ja, das sind Hoymiles-WR und die werden mit einer Ahoy-DTU (ESP32) abgefragt. Aber die Daten werden ja nicht weniger wenn ich eine andere Schnittstelle verwende? Das sind immerhin Daten von 24 PV-Modulen.

Weniger Daten nicht, aber deutlich weniger Event-loops ;) .

Zitat von: Guzzi-Charlie am 13 April 2025, 18:33:49Wenn Du nur 12 Logfiles hast, dann kann Deine Installation ja nicht besonders groß sein.

Dein Denkfehler

ZitatWeniger Daten nicht, aber deutlich weniger Event-loops

Das verstehe ich leider nicht. Magst Du mir das erklären?

Zitat von: Guzzi-Charlie am 13 April 2025, 19:40:02

ZitatWeniger Daten nicht, aber deutlich weniger Event-loops

Das verstehe ich leider nicht. Magst Du mir das erklären?

Mehrere Events können zu einem "bulk" gehören und werden dann zusammen ausgewertet, was z.B. dann für diese Loop nur zu einem Öffnen von FileLog-Dateien führt.

Bei MQTT2_DEVICE entspricht jeder Topic (mind.) einem bulk.

JSON-Blobs werden dabei als ein bulk ausgewertet  ;) .

Zitat von: rabehd am 13 April 2025, 19:35:53

Zitat von: Guzzi-Charlie am 13 April 2025, 18:33:49Wenn Du nur 12 Logfiles hast, dann kann Deine Installation ja nicht besonders groß sein.

Dein Denkfehler

Habe nur 4, sagt count.

Aber meine kleine Installation läuft auch nicht auf einem Pi....

Ich würde da jetzt nicht einfach so an einem funktionierenden System rum machen, ohne die Ursache zu kennen oder zumindest eingegrenzt zu haben. Schau doch mal nach apptime und versuch damit erst einmal zu ermitteln, was bei dir die Laufzeit wirklich frisst. Danach würde ich über Lösungen nachdenken.

Zitat von: mumpitzstuff am 13 April 2025, 22:40:41Ich würde da jetzt nicht einfach so an einem funktionierenden System rum machen, ohne die Ursache zu kennen oder zumindest eingegrenzt zu haben. Schau doch mal nach apptime und versuch damit erst einmal zu ermitteln, was bei dir die Laufzeit wirklich frisst. Danach würde ich über Lösungen nachdenken.

Die Ursache "Ahoy" würde ich auf alle Fälle bereinigen.

Meine Vermutung: die Load tagsüber geht dann nur noch auf um die 60% hoch und man kann dann tatsächlich sinnvolle Analysen über Tools wie z.B. apptime machen...

Da das im Prinzip alle Ahoy-User gleichermaßen betrifft, hier mein Beitrag im "passenden" Tread.

Zitat von: Beta-User am 14 April 2025, 09:06:25Moin zusammen,


nachdem hier (https://forum.fhem.de/index.php?msg=1339313) jemand Probleme mit sehr viel Load hatte, hier mal zumindest meine (etwas bereinigte) aktuelle Fassung für einen der Inverter - Ahoy ist so eingestellt, dass JSON gesendet wird.

Bin mal gespannt, was das an load-Reduzierung in dem betreffenden Thread bringt ;) .

Code Auswählen Erweitern

defmod Inverter_O_Mitte MQTT2_DEVICE inverter_O_Mitte
attr Inverter_O_Mitte alias Ost Mitte
attr Inverter_O_Mitte devStateIcon {FHEM::attrT_Ahoy_Utils::devStateIcon($name)}
attr Inverter_O_Mitte group Solar Inverter
attr Inverter_O_Mitte icon measure_photovoltaic_inst
attr Inverter_O_Mitte jsonMap 1_I_DC:I_DC1 1_P_DC:P_DC1 1_U_DC:U_DC1 1_Irradiation:Irradiation1 1_YieldDay:YieldDay1 1_YieldTotal:YieldTotal1 2_I_DC:I_DC2 2_P_DC:P_DC2 2_U_DC:U_DC2 2_Irradiation:Irradiation2 2_YieldDay:YieldDay2 2_YieldTotal:YieldTotal2 3_I_DC:I_DC3 3_P_DC:P_DC3 3_U_DC:U_DC3 3_Irradiation:Irradiation3 3_YieldDay:YieldDay3 3_YieldTotal:YieldTotal3 4_I_DC:I_DC4 4_P_DC:P_DC4 4_U_DC:U_DC4 4_Irradiation:Irradiation4 4_YieldDay:YieldDay4 4_YieldTotal:YieldTotal4 5_I_DC:I_DC5 5_P_DC:P_DC5 5_U_DC:U_DC5 5_Irradiation:Irradiation5 5_YieldDay:YieldDay5 5_YieldTotal:YieldTotal5 6_I_DC:I_DC6 6_P_DC:P_DC6 6_U_DC:U_DC6 6_Irradiation:Irradiation6 6_YieldDay:YieldDay6 6_YieldTotal:YieldTotal6 1_MaxPower:MaxPower1 2_MaxPower:MaxPower2 3_MaxPower:MaxPower3 4_MaxPower:MaxPower4 5_MaxPower:MaxPower5 6_MaxPower:MaxPower6 Temp:temperature
attr Inverter_O_Mitte model hoymiles_microinverter_inverter
attr Inverter_O_Mitte readingList inverter/O_Mitte/available:.* available\
  inverter/O_Mitte/last_success:.* last_success\
  inverter/O_Mitte/radio_stat:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  inverter/O_Mitte/dis_night_comm:.* dis_night_comm\
  inverter/O_Mitte/ack_pwr_limit:.* ack_pwr_limit\
  inverter/O_Mitte/firmware:.* { json2nameValue($EVENT) }\
  inverter/O_Mitte/hardware:.* { json2nameValue($EVENT) }\
  inverter/O_Mitte/ch0/active_PowerLimit:.* active_PowerLimit\
  inverter/O_Mitte/ch0/ALARM_MES_ID:.* ALARM_MES_ID\
  inverter/O_Mitte/ch0/LastAlarmCode:.* LastAlarmCode\
  inverter/O_Mitte/ch0/Efficiency:.* Efficiency\
  inverter/O_Mitte/ch0/YieldDay:.* YieldDay\
  inverter/O_Mitte/ch0/YieldTotal:.* YieldTotal\
  inverter/O_Mitte/alarm/cnt:.* alarmCnt\
  inverter/O_Mitte/alarm/[\d]+:.* { $TOPIC =~ m,alarm/([\d]+),;; { "alarm_${1}"=>$EVENT } }\
  inverter/O_Mitte/ch0/MaxTemp:.* MaxTemp\
  inverter/O_Mitte/ch1:.* { json2nameValue($EVENT,'1_',$JSONMAP) }\
  inverter/O_Mitte/ch2:.* { json2nameValue($EVENT,'2_',$JSONMAP) }\
  inverter/O_Mitte/ch3:.* { json2nameValue($EVENT,'3_',$JSONMAP) }\
  inverter/O_Mitte/ch4:.* { json2nameValue($EVENT,'4_',$JSONMAP) }\
  inverter/O_Mitte/ch0:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr Inverter_O_Mitte room Steuerung->Strom
attr Inverter_O_Mitte setList reboot:noArg inverter/ctrl/restart/2\
  limit inverter/ctrl/limit/2 $EVTPART1W\
  limit_pct:slider,2,1,100 inverter/ctrl/limit/2 $EVTPART1
attr Inverter_O_Mitte setStateList on off
attr Inverter_O_Mitte webCmd :Durch das jsonMap bleiben dabei die bereits verwendeten Reading-Namen erhalten, man muss also "drumrum" nichts weiter anpassen.

Feedback ist willkommen, bei Gelegenheit wollte ich das auch mal in die attrTemplate einpflegen, bin aber auch überhaupt nicht traurig, wenn sich jemand anderes das mal anschaut und ggf. mit radio-Button die Option anbietet, die JSON-Variante statt der Klartext-Topics zu verwenden.

Hallo,

• mit dem Thema Ahoy-DTU muß ich mich erst noch tiefer beschäftigen. Ich denke im Prinzip habe ich die Idee dahinter verstanden, im Detail allerdings überhaupt noch nicht. Außerdem habe ich 7 Hoymiles-WR die über eine Ahoy-DTU angebunden sind.
• mit dem Thema DbLog habe ich mich schon beschäftigt und mit etwas Suchen im Netz war es dann letztendlich gar nicht so schwierig die mySQL-Datenbank und DbLog einzurichten. Ich habe schon die ersten Devices und SVG's von FileLog auf DbLog umgestellt. Funktionieren tut das problemlos. Ich sehe auch durchaus den evtl. Performance-Gewinn durch Nutzung einer Datenbank anstatt einzelner FileLog-Dateien, aber ich stelle mir gerade schon die Frage "Was ist mit der Dateigröße der Datenbank?". Meine DbLog-Datenbank hat nach einem Tag schon eine Größe von fast 100MB bei nur 5 Devices. Alle meine ca. 5.000 FileLog-Dateien von einem Jahr zusammen haben ca. 50GB. Wie groß darf denn die Datenbank überhaupt werden? Geht das überhaupt mit einer Datenbank, oder müßte ich das dann auch wieder in mehrere Datenbanken aufteilen? Bisher habe ich die FileLogs pro Device und Monat strukturiert und dann so ca. 1x im Jahr die Files vom vorletzten Jahr auf mein NAS verschoben.
• Zu meiner Hauptfrage ob der RasPi 5 für meine Systemgröße überhaupt ausreichend ist, bzw. bei wie vielen Events denn die Grenze liegt die ein RasPi 5 verkraftet gab es leider noch gar keine Antworten.

...ich habe mehr Ahoy-Kanäle wie du ;) ...
Genau aus dem Grund hatte ich damals den issue aufgemacht mit dem Anliegen, eine JSON-Option zu implementieren :P .

Hallo,

ZitatWie groß darf denn die Datenbank überhaupt werden?

Datenbanken wurden entwickelt um seeeehr große Datenmengen performant zu verwalten. Die Größe ist primär durch die Festplattenkapazität begrenzt. Die Performance durch die Rechnerleistung. Aber für Alles gibt es ein Endlich. Hierfür wurden dann spezielle Lösungen als Hardware/Datenbankkombination von den Herstellern entwickelt.

Grüße Jörg

Zum Thema Datenbank Grösse.
Anpassen das nicht alles in die DB geschreiben wird.
Ich setze bei jedem Device zunächst das attr: DBLogExclude auf .*
Dann mit Attr: DBLogInclude alle Readings ich wir brauche.
So halten sich die Menge der Einträge in Grenzen.
Regelmässig mache ich dann Datenbank pflege und lösche nicht benötigte Readings.

Zitat von: GeZi3560 am 15 April 2025, 16:04:43Ich setze bei jedem Device zunächst das attr: DBLogExclude auf .*
Dann mit Attr: DBLogInclude alle Readings ich wir brauche.

Kannst Du Dir so sparen.
attr logdb DbLogSelectionMode Include damit sparst Du Dir DBLogExclude.

Zitat von: Guzzi-Charlie am 15 April 2025, 11:16:14Meine DbLog-Datenbank hat nach einem Tag schon eine Größe von fast 100MB bei nur 5 Devices. Alle meine ca. 5.000 FileLog-Dateien von einem Jahr zusammen haben ca. 50GB.

Der Hinweis auf DbLogValueFn kam wohl nicht an, und die Daten nachträglich auszudünnen geht mit Datenbankfunktionen (=>DbRep) auch "einfacher" als mit LogFiles.

Zitat von: Guzzi-Charlie am 15 April 2025, 11:16:14Zu meiner Hauptfrage ob der RasPi 5 für meine Systemgröße überhaupt ausreichend ist, bzw. bei wie vielen Events denn die Grenze liegt die ein RasPi 5 verkraftet gab es leider noch gar keine Antworten.

Zitat von: Beta-User am 13 April 2025, 12:04:17Da gibt es bestimmt noch viel mehr Ineffizienz, wenn man unter der Haube nachschaut :D .

Anders gesagt: Der Pi ist anscheinend im Moment bei 50% Dauerlast und reagiert _dann_ anscheinend auch noch hinreichend auf irgendwelche deiner Aktionen.

Jetzt reduzierst du die Last via DbLog (ggf. +ValueFn), dann landest du vermutlich bei deutlich verbesserten Werten.

Wenn die Inverter loslegen und auf JSON (+DbLog) umgestellt sind, hast du wieder eine erhöhte Last, klar, aber lass dich überraschen...

Mir wäre das vom Baugefühl her im Egebnis zu viel (da hängen wohl 2 Häuser dran, das klingt nach "relevant für viele Mitmenschen"...), aber der Pi packt das dann schon.

Und dann kannst du ja schauen, ob es tatsächlich die behaupteten ineffizenten Eventhandler (neben FileLog) gibt (Stichwort war apptime...).

Jedenfalls kann man das imo nicht einfach an irgendeiner absoluten Zahl von Events/Zeiteinheit festmachen, die Frage macht nur sehr bedingt Sinn.