benchmark erzeugen

[martinp876]

Hi,

um die Performance einer FHEM Installation prüfen zu können ist es unerlässliche ein paar Daten zu erfassen. Im Besonderen ist dies die Latenz, an 2. Stelle kommt für mich die gesamt-dauer einer Funktion.
Da FHEM single-threated ist und auf der Automation-Seite Reaktionszeiten eine erhebliche Rolle spielen ist es unabdingbar, das Gesamtsystem zu erfassen. Auch der User kann hier Probleme erzeugen, denen er sich nicht bewusst ist.

Im Anhang ist ein Benchmark eingebaut - sollte funktionsfähig sein. Erfasst wird die Performance der timer und aller CallFn. Das Kommando ist "benchmark". Man kann sortieren, filtern, rücksetzen, alle oder nur die top processe ansehen.

Nicht erfasst werden die Präzision der timer (braucht man in HMLAN, wird dort auch gemacht) und "kernal jobs", also fhem.pl eigene Routinen. Auch nicht erfasst werden summen-latenzen. Das sind zwar wichtige FHEM Performance-Indikatoren, die aber nur schwer direkte Rückschlüsse auf den Verursacher zulassen.
Gehalten werden die Daten: für CallFn bei der Entity, für Timer in global. Damit verschwinden die Werte der CallFn wenn die Entity gelöscht wird - hat vor und Nachteile...

Ich hoffe, Rudi kann sich entschließen, es zu übernehmen.

Gruss Martin

[Dr. Boris Neubert]

Hört sich interessant an.

Kannst du was zum Unterschied zur Verwendung eines Profilers sagen (siehe bitte meinen Artikel dazu im fhemwiki)?

Grüße
Boris

[rudolfkoenig]

Das ist doch kein Benchmark, sondern ein Profiler, der an zentralen Stellen mitlaeuft, und das System mAn (d.h. nicht gemessen) deutlich belastet, deswegen werde ich es in dieser Form nicht einbauen.

Es ist aber ohne weiteres als Modul implementierbar: fhem.pl laedt unbekannte Kommandos automatisch (siehe backup, JsonList, usw.), und das Modul kann die benoetigten Funktionen aus fhem.pl ueberschreiben. Nur bitte nicht benchmark nennen, das ist irrefuehrend.

[martinp876]

Hallo Boris,

meinst du den Artikel?
http://www.fhemwiki.de/wiki/DevelopmentProfiling

Ich hatte es weder gefunden noch habe ich es getestet. Wenn ich es recht verstehe ist es auf process-basis. In jeden Fall ist es kein Tool, das User verwenden können. Wenn User wieder einmal timing-Probleme haben, kann man es nicht verwenden. Es ist für die Entwicklung.
FHEM erlaubt aber Usern tasks zu starten  - also timer einzuhängen, sleeps und notifies zu definieren. Es gibt feedback aus dem echten Leben.
Der Fokus liegt auf der Latenzzeit - und dem finden und behandeln von langen Prozessen. m.E. bei einem Konzept dieser Art unabdingbar.
Es ist weit entfernt von einem wirklichen Profiler - der kann erheblich mehr.

falls du einen anderen Artikel meinst, lass es mich wissen.

Hallo Rudi,

profiler - Benchmark... ist mir egal. Der Profiler erzeugt Daten, die man in diesem Fall gegen eine Maßstab vergleiche könnte. Das ist dann die Definition von Benchmark, die ich kenne. Mein Maßstab sind 100ms. Normal werden gleiche Anwendungen verglichen, klar - ich sehe alle Aufrufe als "fhem-tasks", egal was sie tun. Aber profiler (dafür kann es etwas wenig), timing-analyser(begrenzt), latenz-monitor (am ehesten, verstehen aber nicht alle User),..
Aber Namen überlasse ich gerne dir, mir geht es erst einmal um die Funktion.

Die Messung braucht Performance. Auf der FB kostet es 50us die Daten zu ermitteln und zu speichern, was ich leicht auf 30us reduzieren kann.
Die schnellsten Funktionen benötigen 150us - die Erfassung sind demnach 20% plus.
Der am meisten aufgerufene Task (System in ruhe) ist mein IO device (HMLAN), ReadFn. Es macht etwa 50% aller Aufrufe aus. Ein CallFn(readFn) dauert hier im Schnitt 32000us. Das sind dann 1 Promille Performance-Verlust.
Im Schnitt komme ich auf 2,9ms/task.  Es kostet also 1% Performance im Durchschnitt. Das ist ohne die "kernal-CPU" gerechnet, im großen Durchschnitt also weniger.
wenn web-Anwendungen ausgeführt werden sieht der Schnitt schlechter aus, da erhöht er sich schnell auf 4,5ms/task.
Die Datenerfassung stürzt FHEM also nicht ins Chaos.

Man kann die Funktionen sicher überladen. Aber da es zentrale Funktionen sind muss man ständig am Ball bleiben, prüfen was du änderst, und es nachziehen. Die Maintenance sollte also der übernehmen, der auch die "parent-funktionen" bedient - und das bist du.
Das gilt zumindest für die Erfassung. Auswertung kann man gerne auslagern.

Wie siehst du die Lage? Interesse?

Gruss Martin

[rudolfkoenig]

Hallo Martin,

ich selbst habe keine Interesse an solchen Statistiken, da ich bisher nie Probleme dieser Art hatte.
In fhem.pl einbauen will ich es nicht, gegen einem Modul, was ich selbst nicht pflegen muss, habe ich keine Einwende. Da die modifizierten Funktionen vermutlich nicht geaendert werden, sehe ich die Gefahr einer "Fremdplfege" nicht als sehr gross an.

Gruss,
  Rudi

[martinp876]

Hallo Rudi,

um die Funktion "HandleTimeout" zu überschreiben benötige ich die Variablen
%intAt
$nextat

welche lokal in fhem.pl sind.

Kannst du diese "globalisieren"?
Gruss Martin

p.s.:finde ich cool, dass ihr keine Probleme mit Langläufern habt - immerhin hatten die 10sec pings sicher alle tasks aufgehalten. Das zu suchen ist ohne etwas support ein gebastel - und setzt voraus, dass man das environment des Users nachbaut. Ich hätte erwartet, dass hier letztendlich jeder mehr oder weniger, aber immer Probleme hat.

[rudolfkoenig]

Hab die beiden zu der Liste der globalen Variablen hinzugefuegt und eingecheckt.

Gruss,
  Rudi

[martinp876]

danke