Ankündigung

Einklappen
Keine Ankündigung bisher.

v3.5 Plotdarstellung/-performance

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    v3.5 Plotdarstellung/-performance

    Hallo miteinander,

    mit v3.4 wird ein Beispielplot in ca. 1 Sekunke geladen und so dargestellt:
    Screenshot 2025-02-21 210624.png

    Mit v3.5 dauert das Laden mehrere (~10) Sekunden und wird dann so dargestellt:
    Screenshot 2025-02-21 210658.png

    Weiter ist die Seitenperformance sehr schlecht, vorallem mit mehreren, auch einfachen, Plots. Teilweise reagiert die Seite gar nicht mehr, auch wenn nur der oben abgebildete Plot drauf ist. In v3.4 läuft das alles flüssig.

    Um auszuschliessen, dass ich irgendwelche Altlasten habe, habe ich die v3.4 und 3.5 jeweils komplett neugeladen, installiert und minimal konfiguriert, eine neue Page aus dem Template erstellt und in room_sleeping.html nur den Plot
    Code:
    {{ plot.period('pv-leistung', ['knx_0_6_20','knx_0_6_200', 'knx_0_6_10'], 'avg', '1w', '', '0', '6000', '', ['Bezug','Erzeugt','Bedarf'], ['green','yellow','red'], ['areastack','areastack','line'], ['Zeit','Watt'], 'advanced') }}
    eingefügt.

    Beste Grüße
    Patrik

    #2
    Moin Patrik PatrikG,

    Bei den Plots sind 2 wesentliche Änderungen gemacht worden:
    1. series-items für Plots haben das Format 'myItem.mode.tmin.tmax.count' und müssen beim Backend mit einem eigenen Kommando angefordert werden. Zur Erkennung wird der item-Name an seinen Punkten zerlegt und geprüft, ob an viertletzter Stelle eine der Datenbank-Aggregationsfunktionen (Modi) verwendet wird. Bis v3.4 war das in der base.js hart codiert:
      Code:
      return ($.inArray(aggregate, Array('avg', 'min', 'max', 'sum', 'diff', 'rate', 'on', 'raw', 'count')) >= 0);
      Da smarthomeNG weitere Modi erhalten hat, habe ich in v3.5 die erlaubten Modi in den jeweiligen Treiber verlegt. Im OpenHAB-Treiber sind die wie folgt definiert:
      Code:
      aggregates: ['avg', 'min', 'max', 'sum', 'diff', 'on', 'raw', 'count'],
      Wenn da nicht etwas schief gelaufen ist, sollte dies keine Änderung in der Kommunikation mit OpenHAB bedeuten. Es wäre aber gut, wenn Du das nochmal prüfen könntest.
      .
    2. Zur Beschleunigung der Plots wurden doppelte "Redraw"-Befehle beim Update von Serien eliminiert und es wurde der Boost-Modus von Highcharts aktiviert:
      - im html-Teil des Widgets wird das Boost-Modul geladen, wenn die Aggregationsfunktion (mode) "raw" ausgewählt ist, oder count >= 5000 ist. Beides ist bei Dir nicht der Fall.
      - um das Boost-Modul endgültig zu aktivieren, wird im js-Teil der data-grouping-Modus abgeschaltet, wenn die tatsächliche Anzahl der Punkte pro Serie bei 5000 oder mehr liegt.

      Hier könnte ein Problem liegen: wenn OpenHAB sich nicht an die Anzahl der angeforderten Punkte (in Deinem Beispiel nicht definiert, also default 100) pro Serie hält und über 5000 Punkte schickt, dann wird das Boost-Modul nicht geladen und trotzdem data-grouping abgeschaltet. Dann muss Highcharts jeden einzelnen Punkt als SVG rendern und das führt sehr wahrscheinlich zu der langen Antwortszeit. Der Plot sieht so aus, als ob deutlich mehr als 100 Punkte pro Serie übertragen werden. Abhilfe in diesem Fall wäre, im Widget-Aufruf den Parameter "count" auf 5000 zu setzen.
    Ich versuche mal parallel, den Fall 2 mit dem Offline-Treiber nachzustellen.

    Gruß
    Wolfram

    EDIT: bei mir bestätigen sich die Hypothese und die Abhilfe, wenn ich den offline Treiber entsprechend modifiziere, also das Backend den Parameter 'count' ignoriert,
    Zuletzt geändert von wvhn; 22.02.2025, 08:52.

    Kommentar


      #3
      Hallo Wolfram wvhn,

      mit count =5000 ist der Aufbau zwar ca. 50% schneller, was immer noch wesentlich länger als voher ist, aber die Flächen werden trotzdem nicht sauber gefüllt. Manchmal ist auch die Reihenfolge "falsch". Bei v3.4 kommt immer erst der grüne Teil, dann der gelbe darüber und dadrüber dann die rote Linie. So ist es auch gewünscht. Bei v.3.5 kommt manchmal zuerst der grüne, manchmal aber auch der gleibe Teil zuerst und dann stimmt natülich die Enddarstellung nicht so wie gewünscht.Screenshot 2025-02-22 130428.png

      Es ist der Tat so, dass der Treiber den count nicht verwendet, da man bei OpenHAB, zumindest damals, beim Abrufen der gespeicherten Daten nur Anfangs- und Endzeit angeben konnte. Man hätte die Anzahl, wenn dann, anschliessend im Treiber reduzieren müssen. Was mir aber damals unsinnig erschien, da diese ja schonmal da waren und der Sinn dahinter wohl eher ist, dass man gar nicht erst alle Daten vom Backend abruft.

      Ich habe mich damit auch nicht weiter beschäftigt, da dies bei meinen Tests, und ich mache wirklich viel mit Plots, da die Plots einer der Hauptgründe für SmartVISU waren, bis v3.4 auch keine Beeinträchtigungen hatten. Der obige Plot hat z. Bsp. ca 100.000 Datenpunkte je Item und wird bei v3.4 ohne Cache innerhalb einer Sekunde abgerufen und angezeigt. Ich hab noch andre Seiten mit ca. 50 Plots mit nur einem Item je Plot und diese ist unter v3.4 nach ca. 5 Sekunden vollständig gerendert und kann flüssig gescrollt werden. Das geht mit der v3.5 gar nicht, da hängt dann der Browser.

      Ich schau mal, ob man da treiberseitig was machen kann.

      Gruß
      Patrik
      Zuletzt geändert von PatrikG; 22.02.2025, 13:45.

      Kommentar


        #4
        Moin Patrik PatrikG,

        am besten setzt Du in der ./widgets/plot.js in Zeile 397 "enabled: false". Dann wird der Boost-Modus nicht aktiviert und data-grouping nicht abgeschaltet. "count" kannst Du dann im Widget-Aufruf wieder leer lassen. Parallel schau ich mal, ob ich den Boost-Modus noch verbessern und gezielter einschalten kann.

        Es gibt im gitHub-Repository von Highcharts einige Issues zum Thema Highstock und Boost, die seit längerer Zeit nicht gelöst sind. Das ist auch der Grund, warum smartVISU immer noch die Version 11.0.1 verwendet, weil die bestimmte Fehler noch nicht enthält. Es kann also mit einer verbesserten Version in smartVISU noch etwas dauern.

        Treiberseitig würde ich nichts machen, da man sonst nachträglich nochmal über mehrere Intervalle mitteln und viele Werte löschen muss. Das ist eigentlich die Aufgabe der SQL-Abfrage im Backend.

        Gruß
        Wolfram
        Zuletzt geändert von wvhn; 22.02.2025, 15:02.

        Kommentar


          #5
          Hallo Wolfram wvhn,

          in der zwischenzeit habe ich den Treiber temporär so angepasst, dass dieser zwar alle Daten der Zeitspanne vom Backend holt, aber nur die Anzahl gemäß count an widget.update übergibt.

          count = '' (100), ohne Zoom:
          Screenshot 2025-02-22 155748.png

          count = 1000; ohne Zoom:
          Screenshot 2025-02-22 155824.png
          count = 1000; Zoom 1T:
          Screenshot 2025-02-22 155849.png

          count = 5000; ohne Zoom:
          Screenshot 2025-02-22 155935.png

          count = 5000; Zoom 1T:
          Screenshot 2025-02-22 160045.png

          Ab 10.000 bleibst ähnlich, wird aber langsamer. Natürlich stimmen die gespeicherten Zeiten der drei Items nicht 100%-ig überein. Je weniger Datenpunkte, desto weiter können diese auseinander liegen.

          Wenn ich, wie von dir vorgeschlagen, den Boostmodus deaktiviere, dann ist es wieder so wie voher. Danke.

          Beste Grüße
          Patrik
          Zuletzt geändert von PatrikG; 22.02.2025, 16:33.

          Kommentar


            #6
            Hier nochmal eine Zusammenfassung der Situation:
            • smartVISU verwendet Highcharts Stock, eine Erweiterung von Highcharts speziell für Zeitreihen.
            • Highcharts Stock verfügt über zwei Konstruktoren: "chart" und "stockChart". Letzterer wird in plot.period nur bei Plots mit Zoom-Modus "advanced" aktiviert und bringt u.a. den Navigator für den Zoom mit.
            • Highcharts Stock beinhaltet auch die Option "dataGrouping", die in "stockChart" - also für alle Plots mit zoom = "advanced" - standardmäßig aktiviert ist und dafür sorgt, dass bei großen Datenmengen Punkte in einem Raster von zwei Pixeln zusammengefasst werden. Das verfälscht zwar den Kurvenverlauf etwas, beschleunigt das Rendern des Plots aber enorm.
            • Da die Gruppierung der Daten bei großen "stair"-Plots zu Anzeigefehlern führt, habe ich sie in v3.3 für alle "stair"-Plots ausgeschaltet. Dabei habe ich sie aber unbeabsichtigt für alle anderen Plots aktiviert. (Ich war davon ausgegangen, dass die Option nur für den Typ "stockChart" gilt und beim Typ "chart" ignoriert wird. Das ist aber offenbar nicht richtig. Klärung im Highcharts-Forum läuft.)
            • Ist die Gruppierung der Daten abgeschaltet, dauert das Rendern von Kurven mit großen Datenmengen sehr lange - zu Gunsten der Genauigkeit. Der Boost-Modus verkürtzt dies massiv, ist aber langsamer als die Darstellung mit gruppierten Daten. Allerdings hat der Boost-Modus ein Problem mit gestackten Datenreihen und beschleunigt die Darstellung nicht wesentlich.
            • Wenn das Backend wesentlich größere Datenmengen liefert, als im Widget parametriert, wird die Datengruppierung abgeschaltet, aber das Boost-Modul nicht aktiviert. Das führt zu dem beobachteten Verhalten. Bei den "stacked"-Typen wirkt der Boost-Modus nicht wirklich und deshalb hat die erste Abhilfe (count = 5000) hier nicht geholfen.
            Sorry für die Ausführlichkeit der Erklärung, aber mir ist wichtig, die Zusammenhänge im Sinne einer Entwickler-Doku festzuhalten.

            Sobald meine Anfrage im Highcharts-Forum geklärt ist, werde ich mir Gedanken machen, wie man die Datengruppierung und den Boost-Modus im Widget transparent steuern kann.

            Gruß
            Wolfram
            Zuletzt geändert von wvhn; 01.04.2025, 17:13. Grund: Schreibfehler korrigiert

            Kommentar


              #7
              Sorry für die Ausführlichkeit der Erklärung, aber mir ist wichtig, die Zusammenhänge im SInne einer Entwickler-Doku festzuhalten.
              Also mich betrifft das Problem nicht, aber aus Interesse lese ich die langen Beschreibungen trotzdem gerne.

              Danke!

              Kommentar


                #8
                Laut Highcharts Forum bringen die beiden Konstruktoren die gleichen Optionen mit und unterscheiden sich nur durch die Default-Werte, z.B. den aktivierten Navigator bei Highcharts.stockChart.

                Ich habe mich jetzt entschlossen, das Thema wie folgt zu lösen:
                • in der Darstellung ohne zoom="advanced" wird das Boost-Modul immer geladen, wenn in den Widget-Parametern der Modus "raw" oder count >= 5000 angegeben ist. Der Boost-Modus greift dann automatisch ein, sobald eine Serie tatsächlich 5000 oder mehr Punkte hat. Die Darstellung des Plots ist damit immer möglichst nah an den Originaldaten. Die Option „dataGrouping“ bleibt hier deaktiviert (wie vor SV v3.3).
                • in der Darstellung mit zoom="advanced" ist dataGrouping standardmäßig eingeschaltet, was schneller als das Boost-Modul ist. Die Darstellung ist dann zwar bei großen Datenmengen weniger genau, gewinnt aber an Genauigkeit, je mehr man hineinzoomt. Das Widget lädt in diesem Fall das Boost-Modul nicht (mehr).
                Das sollte die üblichen Anwendungsfälle abdecken. Wer das Verhalten ändern möchte, kann den Boost-Modus im Parameter „chartoptions“ deaktivieren, oder - falls das Boost-Modul bei zoom='advanced‘ doch verwendet werden soll - das Skript in der html-Seite vor dem Widget-Aufruf importieren.
                Code:
                <script src="vendor/plot.highcharts/modules/boost.js"></script>
                Gruß
                Wolfram

                Kommentar

                Lädt...
                X