plotEmbed=2 implementiert

[rudolfkoenig]

Kurz:
falls das FHEMWEB Attribut plotEmbed auf 2 gesetzt wird (und plotFork entweder nicht gesetzt wird, oder auf 1 steht), dann werden die SVGs ab sofort parallel berechnet.

Lang:
- frueher konnten Browser SVGs nur per <embed> Tag darstellen. Das hat den Vorteil, das (mit gesetzten plotFork) der FHEM-Server die SVGs parallel berechnen kann, und den Nachteil dass die Manipulation (z.Bsp. verschieben) per JavaScript langsam ist/flackert. Um diese Methode zu waehlen setzt man plotEmbed 1

- mit plotEmbed 0 (Voreinstellung) werden die SVGs "inplace" (also ohne <embed> Tag) gerendert. Nachteil: Bei vielen/grossen SVGs dauert das lange, weil ein Prozessor die ganze Seite (== alle SVGs auf der Seite) erst berechnen muss.

- ich habe vor ca einem Jahr versucht plotEmbed=0 zu parallelisieren: mit plotFork=1 und plotEmbed=0 wird die Berechnung der SVG per BlockingCall parallel gemacht. Leider hat das ein Problem: Falls die Berechnung laenger als etwa 90sek dauert, sendet Chrome (warum auch immer) die Anfrage nochmal. Da das "Haupt-FHEM" mit plotFork=1 nicht blockiert ist, wird die Berechnung erneut angestossen, und das Ergebnis verwirrt sowohl FHEMWEB, wie auch Chrome. Details siehe hier.

- mit plotEmbed=2 sollte das Problem geloest sein. Das "Haupt-FHEM" erstellt die Seite ohne die SVGs, und der Browser bestellt jetzt ueber JavaScript die SVGs einzeln nach, was parallelisiert werden kann.

Ich habe vor plotEmbed=2 als Voreinstellung einzufuehren, wenn keine Probleme auftauchen.

[Nestor]

I had previous config with plotembed and plotfork set to 1, because Fhem froze when calculating rooms with multiple graphs. The new plotembed=2 seems to work fine here, with the advantage of not forking additional Fhem processes. Good stuff!

[Icinger]

Funktioniert super, Seiten mit mehreren Diagrammen werden jetzt viel schneller aufgebaut.
Einziger Wermutstropfen bislang:
Die Farb-Einstellungen vom Flex-Style werden nicht übernommen, sondern die Standard-Farben verwendet.
Darum muss ich aber vmtl. eher der Flex-Author kümmern, oder?

Schönen Abend noch,

Stefan

[rudolfkoenig]

The new plotembed=2 seems to work fine here, with the advantage of not forking additional Fhem processes.

Sorry to disappoint you, but plotEmbed implies plotfork=1 (if plotfork is not set expicitely to 0), and it forks off FHEM processes for rendering the SVG just the same as plotEmbed=1 with plotfork=1

[Maista]

Moin,

Funktioniert bei mir auch flott.
20 Bilder auf einer Seite mit einem Rpi3B.
Browser ist Opera.

Danke.

Gerd

[gichtl]

plotfork=1 führt auf einer Seite mit n-Plots zu n+1 perl Prozessen. Also einen für das "Haupt-FHEM" und n für jeden Plot.

bei plotEmbed=2 hingegen sind es maximal 1+5 perl Prozesse.

Auf sehr schwacher (aber auch sehr starker) Hardware ist das suboptimal, da die Zeit bis sich auf der Seite was tut und die ersten Plots angezeigt werden, manchmal doch recht hoch ist. Und dann werden alle Plots quasi gleichzeitig angezeigt. Besser wäre wenn man die verfügbare CPU Leistung auf die ersten Plots optimal konzentrieren könnte. Damit würden diese zügiger gezeichnet, und die Plots weiter unten auf der Seite entsprechend später.

Für plotEmbed gibt es im Gegensatz zu plotfork offenbar schon eine fixe Grenze von 5 nebenläufigen Prozessen. Wäre es möglich die fork-Grenze konfigurierbar zu machen und/oder auf $numCPUs zu ändern?

[rudolfkoenig]

Auf sehr schwacher (aber auch sehr starker) Hardware ist das suboptimal, da die Zeit bis sich auf der Seite was tut und die ersten Plots angezeigt werden, manchmal doch recht hoch ist.

Ich kann mich nicht beschweren, bei mir funktioniert es so, wie ich es mir wuensche.

Besser wäre wenn man die verfügbare CPU Leistung auf die ersten Plots optimal konzentrieren könnte.

Ich habe zwar eine andere Meinung, habe aber absolut nichts dagegen, wenn das in einem anderen Modul so realisiert wird.
Fuer ausgefeilte Plot-Wuensche ist womoeglich DbLog + Grafana eine Alternative.

Für plotEmbed gibt es im Gegensatz zu plotfork offenbar schon eine fixe Grenze von 5 nebenläufigen Prozessen.

Diese Grenze stammt vom Browser, da pro Seite maximal 6 Verbindungen geoeffnet werden, und #1 ist mit dem longpoll/websocket Kanal belegt. Mit plotfork=1 und plotEmbed=0 wird der BlockingCall Mechanismus verwendet, den man begrenzen kann (attr global blockingCallMax). Das hat allerdings andere Probleme, wenn die Berechnung eines Plots laenger als 90 Sekunden dauert, und ich wollte es deswegen auch schonmal ausbauen.

[gichtl]

Danke für die Info! Mit der impliziten Browser Grenze bremst man einen schnellen fhem-Server mit mehr als 5 Cores aus, da hier auch nur 5 Plots gleichzeitig gerendert werden können. Dort würde sich vermutlich plotfork alleine anbieten. Beim Firefox läßt die sich im Gegensatz zum Chrome die Grenze noch ändern, aber das ist auch nicht praktikabel und somit auch keine Alternative. DbLog + Grafana hingegen sind für meine Anwendung Overkill und würden die Büchse sprengen.

plotEmbed=2 ist schon fast perfekt, da hier zumindest schon mal das Seitengerüst fertig angezeigt wird und die Plots dann eben unkontrolliert eintrudeln, während bei plotfork=1 und plotEmbed=0 erst alle Plots fertig gerendert werden müssen bis sich überhaupt was am Bildschirm tut.

Aber ich sehe auch daß die serverseitige Kontrolle der nebenläufigen Plot-Prozesse nicht trivial ist. Dann soll es eben so sein.