Seite lädt nicht mehr und "modules.websocket.sv Exception"

[Tom Bombadil]

Würde bedeuten, dass durch einen Neustart oder Cache leeren angestoßen wird?!?

Das deckt sich mit meinen Beobachtungen (wir hatten das Thema ja schon mal). Ich habe auch Temperatur-eval's an 10 Items und bekomme nach jedem Neustart irgendwann (nie gleich am Anfang - manchmal erst Stunden später, aber zu keinem reproduzierbaren Zeitpunkt) die Worker Thread Warnung im Log. Danach ist dann Ruhe, die Meldung kommt nie wieder.

Beispiel eines der Items:

heizung:

    sensoren:
    
        af1:

            desc: Außenfühler 1
            type: num
            trovis557x_var: AussentempAF1
            liste: []
            visu_acl: ro
            database: 'init'
            invalid_to_zero: True

            af1min24h:
                desc: Minimumtemperatur (24h)
                type: num
                eval: round(sh...db('min','24h', 'now'),1)
                eval_trigger: ..

            af1max24h:
                desc: Maximumtemperatur (24h)
                type: num
                eval: round(sh...db('max','24h', 'now'),1)
                eval_trigger: ..

            af1avg24h:
                desc: Durchschnittstemperatur (24h)
                type: num
                eval: round(sh...db('avg','24h', 'now'),1)
                eval_trigger: ..

            af1min7d:
                desc: Minimumtemperatur (7d)
                type: num
                eval: round(sh...db('min','7d', 'now'),1)
                eval_trigger: ..

            af1max7d:
                desc: Minimumtemperatur (7d)
                type: num
                eval: round(sh...db('max','7d', 'now'),1)
                eval_trigger: ..

            af1avg7d:
                desc: Minimumtemperatur (7d)
                type: num
                eval: round(sh...db('avg','7d', 'now'),1)
                eval_trigger: ..

Vielleicht hilft es ja, das mal einzukreisen. Störend ist es hier nicht, die Plots funktionieren normal, und die Verzögerung beim Seitenaufbau in der Visu schiebe ich auf Daten von 5 Jahren, die nie aufgeräumt wurden.

/tom

[ooUrmeloo]

mal wieder ein kurzes Update ... leider keine Besserung hier.
Irgendwie habe ich das Gefühl, dass je länger ich eine Seite nicht aufgerufen habe, desto länger dauert es und desto höher die Wahrscheinlichkeit, dass websocket Fehler kommen - oder Cache leeren.
Aktuell haben sich die Threads auf 235 "hochgeschraubt", davon allerdings 208 idle ...

[ooUrmeloo]

So ... ich habe das Problem mittlerweile umgangen, indem ich die Min-/Max-Werte "kaskadiert" berechnen lasse anstatt alles über Datenbank-Befehle mit den Temperatur Rohdaten zu berechnen. D.h., ich schreibe min/max täglich in einen Datenbankeintrag und triggere dann wöchentlich, wieder in Datenbank, etc. So reduzieren sich die Datenbank-Aufrufe und vor allem auch die langen Berechnungszeiten beim Jahres-min/-max.

websocket und database Fehler treten seitdem nicht mehr auf, und Threads bleiben auch im Rahmen. Und Seiten laden auch wieder schnell.
Problem also nicht ganz behoben aber zumindest vermieden ...

Ich glaube aber immer noch, dass ich das Problem früher nicht hatte. Keine Ahnung, ob das an SHNG 1.9.5 liegen kann (das habe ich nicht mehr geändert). Mit SmartVisu 3.3.1 bestand das Problem auch, das habe ich probiert. Oder ob es halt doch an der mittlerweile angewachsenen Größe meiner Database liegt.

[wvhn]

Vielen Dank für die Rückmeldung. Kannst Du noch schreiben, auf welcher Hardware und welcher Linux-Version shNG v1.9.5 bei Dir läuft?
Wenn die Hardware nicht allzu lahm ist, dann ist das Verhalten IMHO nicht normal und wir sollten das weiter im Auge behalten.

Gruß
Wolfram

[ooUrmeloo]

Vielen Dank für die Rückmeldung. Kannst Du noch schreiben, auf welcher Hardware und welcher Linux-Version shNG v1.9.5 bei Dir läuft?
Wenn die Hardware nicht allzu lahm ist, dann ist das Verhalten IMHO nicht normal und wir sollten das weiter im Auge behalten.

Gruß
Wolfram

Raspbian bullseye auf einem Raspberry 3B

[wvhn]

Moin,
da ich bisher keine große Datenbank habe und auch keine Seiten mit richtig großen Datenmengen in Plots hatte, konnte ich das geschilderte Verhalten nicht nachvollziehen. Ich bin deshalb immer davon ausgegangen, dass die Datenbank und das Websocket-Modul in shNG außer Tritt geraten. Das ist vermutlich auch so, aber die Visu kann dies durch verzögerte Antworten auf der Websocketverbindung auslösen.

Das "Aha"-Erlebnis hat sich beim Testen der Seiten eines Anwenders eingestellt, der in einzelnen Plots bis zu 4 Kurven mit je 200.000 Datenpunkten (!) hat. Jetzt muss man wissen, dass Highcharts die Plots als SVG-Elemente darstellt - je eines für jeden Abschnitt zwischen zwei Datenpunkten und ggfls. weitere für Eigenschaften der Darstellung (Symbole, Schattierungen ...). Mit diesen riesigen Mengen an SVG-Elementen kommt der Browser aus dem Rendern nicht mehr raus und ist nicht mehr flüssig bedienbar. Man sieht das z.B. an der sprunghaften Bewegung des Tooltips, wenn man mit der Maus über die Kurven fährt. Wenn man dann noch versucht, das Plot-item in den Entwicklertools anzeigen zu lassen, friert der Browser für Minuten ein. (Das ganze habe ich übrigens mit einem leistungsfähigen aktuellen PC als Client getestet). Es liegt nahe, dass der Browser bei dieser hohen Auslastung auch als Websocket-Client nicht mehr innerhalb der erwarteten Timeouts antwortet.

Highcharts bringt für Plots mit großen Datenmengen das Modul "boost" mit, das auf Geschwindigkeit getrimmt ist. Es schaltet sich automatisch oberhalb einer Datenmenge von 5000 Punkten ein. Das Modul werde ich jetzt in den nächsten Schritten testen und auf (hoffentlich) geeignete Weise einbinden. Ein erster Test ergab beeindruckende Verbesserung an der flüssigen Bedienbarkeit der Seite. Auch die Ladezeiten sind gefühlt besser, wobei natürlich die Übetragung der großen Datenmengen auf der Websocketverbindung nicht beeinflusst werden kann. Wer das testen möchte, kopiert einfach die boost.js aus dem Ordner ./vendor/plot.highcharts/modules in den Ordner ./dropins/widgets. Von dort wird sie in SV-Versionen ab v3.0 automatisch importiert.

Für Testberichte wäre ich dankbar.

Gruß
Wolfram

[AndreK]

Hi wvhn,

ich habe die "boost.js" mal wie von Dir vorgeschlagen ins Dropin-Verzeichnis kopiert. Ich habe zwar aktuell keine "Mega"-Plots, das Laufzeitverhalten ist aber trotzdem
wesentlich besser. Am Montag werde ich das nochmal in einer anderen Umgebung testen, dort habe ich "Mega-Plots".

Aktuell hatte ich keine Web-Socket-Fehler in den vorhandenen Umgebungen - das Laufzeitverhalten war trotzdem eher mäßig.Ich werde berichten.

Super Hinweis, schonmal vielen Dank an dieser Stelle.

Viele Grüße
Andre

[AndreK]

Hallo,

ich habe getestet. Das reine importieren der Boost.js reicht nicht. Ich habe die chart-Options im jeweiligen Chart mit :

boost: {useGPUTranslations: true}

ergänzt. Dann geht der Aufbau der Charts, nach meinem Empfinden, wirklich schneller.

Grüße
Andre

P.S.: Highcharts Version 11.0.1 und smartVisu 3.4 - mit Vorgängerversionen hatte das nicht korrekt funktioniert.

[wvhn]

Moin Andre,

Danke für den Hinweis, der mir geholfen hat, die Doku genauer zu lesen. Es liegt offenbar an den Plots, die man darstellt. Das Boost-Modul schaltet sich automatisch ein. Dazu braucht man die Option useGPUTranslations nicht. Diese kann zusätzlichen Schub verleihen, aber auch zu Darstellungsfehlern insbesondere bei Zeitreihen führen.

This option may cause rendering issues with certain datasets. Namely, if your dataset has large numbers with small increments (such as timestamps), it won't work correctly. This is due to floating point precision.

An einer Stelle in der Doku wird aber auf Überschneidungen mit der Option dataGrouping hingewiesen, die in smartVISU standardmäßig aktiviert ist (da smartVISU Highcharts Stock verwendet). Evtl. muss man die Option bei großen Plots in den chartoptions abschalten. Das muss ich mir noch näher ansehen.

Gruß
Wolfram

[AndreK]

Hallo Wolfram,

noch ein kleiner Hinweis, falls Du das nicht schon gesehen hast. Die Import Reihenfolge spielt wohl auch eine Rolle. Wenn die boost.js im Dropin-Verzeichnis steht ist dann
gewährleistet das diese nach dem Import von Highcharts erfolgt ?

import Highcharts from "highcharts";
import HighchartsBoost from "highcharts/modules/boost";
// Import order is important !
HighchartsBoost(Highcharts);
// Then you can use your Highcharts as usual

[wvhn]

Hallo Wolfram,

noch ein kleiner Hinweis, falls Du das nicht schon gesehen hast. Die Import Reihenfolge spielt wohl auch eine Rolle. Wenn die boost.js im Dropin-Verzeichnis steht ist dann
gewährleistet das diese nach dem Import von Highcharts erfolgt ?

Ja. Die Dateien in ./dropins werden sehr weit am Ende des Ladeprozesses importiert. Siehe auch die neue Seite "User Extensions" in der Doku von v3.4.
Das Ablegen in ./dropins ist nur als Workaround für die aktuelle smartVISU Version gedacht. In der nächsten Version werde ich die boost.js explizit nach den anderen Highcharts-Modulen in der ./pages/base/root.html einbinden.

Gruß
Wolfram

[wvhn]

Mit der debug-Option des boost-Moduls habe ich noch einen Fehler gefunden, der seit smartVISU v3.2 besteht und zur Folge hat, dass jede Serie doppelt gerendert wird - einmal beim update der Daten und sofort anschließend beim Neuzeichnen des Charts. Dies kann man abstellen, indem man die entsprechenden Optionen für series.setData() auf false setzt.
Neu in der ./widgets/plot.js ab Zeile 579 (SV v 3.4):

               chart.series[seriesIndex].setData(values, false);
            }
            else if (response[i]) {
                chart.series[seriesIndex].setData(response[i], false);​

und analog für plot.xyplot auch in Zeile 1855. Das sollte schonmal eine bedeutende Verbesserung bringen.

An der Integration des boost-Moduls arbeite ich weiter. Tatsächlich verweigert das seinen Dienst, wenn series.dataGrouping enabled ist, was in den meisten Fällen der Fall ist, außer bei den "stair" plots.

Gruß
Wolfram

[wvhn]

Moin,

in diesem gist ist jetzt eine plot.js, in der die Option dataGrouping für jede Serie dynamisch ausgeschaltet wird, die 5000 und mehr Datenpunkte hat. Damit kann das Boost-Modul, das sich ab 5000 Punkten aktiviert, den Plot über WebGL rendern, was deutlich schneller ist, als der SVG-Renderer. Beim Zoomen in einen Bereich unter 5000 Punkte wird dann wieder auf den SVG-Renderer gewechselt, so dass keine Details verloren gehen. Die Datei ist mit smartVISU v3.4 kompatibel.

Zum Testen reicht es aus, die Datei boost.js in den Ordner ./dropins zu kopieren, wie oben beschrieben. In meinem allerersten Test hatte ich zufällig eine Grafik, in der Plots vom Typ "linestair" verwendet wurden, so dass dataGrouping schon abgeschaltet war. Dies zur Erklärung, warum ich andere Ergebnisse bekommen habe, als AndreK.

Die Änderung ist noch nicht im develop branch, weil ich die mit weiteren Änderungen pushen will, die noch zum - ggfls. bedarfsweisen - Import der boost.js vornehmen muss.

Gruß
Wolfram