NEWS
[gelöst] Object Binding+viele Aktualisierung=View langsam
-
Hallo zusammen,
ich nutze seit langem eine recht gefüllte View, welche mir alle möglichem Smart-Home Daten anzeigt. Ich verwende fast immer HTML-Widgets, welche ich dann völlig frei gestalten kann und die Werte per Object Binding dort anzeigen lasse.
Bisher habe ich damit auch wenig Probleme, da bspw. Temperatur, Luftfeuchtigkeit und Thermostatstellungen meiner angezeigten 12 Räume sich nicht hochfrequent ändern. Neben dieser Heizungsdarstellung habe ich auch noch viele statische Buttons und ein MotionEye-Frame in der View.
Vor allem die linke Seite hat Werte die sich ändern. Rechts sind diese eigentlich nicht vorhanden. Der Graph ist ein Grafana iframe. Es gibt keine zusätzlichen Views in dem Projekt, welche im Hintergrund auch viel Last erzeugen.
Da ich seit neustem eine PV Anlage plus Speicher habe, will ich natürlich jetzt die Energieflüsse darstellen. Das hatte ich jetzt schön gebaut (sieht man nicht in der View, da ich es schon wieder ausgebaut habe) und wieder per Object Binding zu den Werten verlinkt. Jetzt scheint aber die Wechselfrequenz der Werte so hoch zu sein (~2x pro Sekunde je Wert), dass die View (läuft auf einem Samsung A7 Tablet) extrem langsam wird.
Jetzt die Frage:
- mache ich hier grundlegend etwas falsch und sind HTML-Widgets eher "langsam" oder problembehaftet?
- Wie sollte man es richtig machen? (mir gefallen sehr selten die angebotenen Widgets, so dass ich hier alles selber "designe")
- Wie kann ich es hinbekommen, dass ich Werte aus Objekten nur alle x Sekunden aktualisieren lasse, obwohl sich der zugrundeliegende Wert mehrfach die Sekunde ändert. Mir würde jetzt nur der Weg über zusätzliche Objekte einfallen, welche seltener beschrieben werden.
Geht das aber vielleicht auch mit Bordmitteln?
Könnte man vielleicht auch Grafana dazu benutzen, um Einzelwerte anzuzeigen bzw. an VIS weiterzugeben? Damit könnten dann ggf. auf 5min Mittelwerte oder sowas gehen, die seltener schwanken...
Performance ist für mich ein großes Manko an Vis generell. Ein Memory-Leak in der Kombination aus Updateintervall und Object Binding hatte ich in dem Zusammenhang auch schon. Das ist nun aber beseitigt. Dennoch wird bei vielen Datenpunkten und häufiger Aktualisierung die View langsam. Das sollte eigentlich nicht passieren.
Hat jemand Ideen?
Viele Grüße
SebastianDie Lösung ist die Nutzung eines View-seitigen Javascripts, in dem man
- selbst die Häufigkeit der Aktualisierung bestimmt und
- (und das ist das Wichtigste) die Änderung des Werts nur auf das HTML-Element beschränkt, welches den Wert anzeigt. So wird nicht das ganze Widget neu gerendert
const myTimeout = setInterval(updateValue, 1000); function updateValue() { $.ajax({url: "http://addresse:8082/getPlainValue/javascript.0.Strom.ConsumptionOnInputL2power", success: function(result){ $("#TextID").html(result); }}); }
Wobei in bspw. einem HTML-Widget dann der Wert in einem bspw. DIV mit der ID "TextID" eingefasst wird
-
eine vis ist nicht gedacht, um realtime werte anzuzeigen, die sich mehrfach pro sekunde ändern - dazu bräuchte man wohl eine schnellere anbindung (lan) und eine performante maschine (geht ja in den bereich messtechnik und macht wenig sinn für eine vis, da du für die paar sekunden, die du am tag darauf schaust, den rest vom tag immensen traffic erzeugst).
- hast du das browser log auch mal gecheckt, ob da fehler kommen ? (chrome entwicklertools)
- wie schnell reagiert das ganze, wenn du die view am pc in chrome öffnest ? ist sie dort auch langsam ?
@seb2010 sagte in Object Binding + viele Aktualisierung -> View extrem langsam:
Mir würde jetzt nur der Weg über zusätzliche Objekte einfallen, welche seltener beschrieben werden.
du könntest dir in der vis ein script schreiben, welches die werte im html widget mit einem interval setzt - in der vis eine eher komplexere aufgabe - im javascript adapter leicht zu machen und das ergebnis in neue datenpunkte schreiben (periodisch)
-
@seb2010 sagte in Object Binding + viele Aktualisierung -> View extrem langsam:
Könnte man vielleicht auch Grafana dazu benutzen, um Einzelwerte anzuzeigen bzw. an VIS weiterzugeben? Damit könnten dann ggf. auf 5min Mittelwerte oder sowas gehen, die seltener schwanken...
ja das ist möglich
https://github.com/ioBroker/ioBroker.influxdb#custom-queries -
@liv-in-sky naja, also großer Traffic sieht anders aus und belastet die heutige Bandbreiten auch nur wenig. Und mit Messtechnikperformance Anforderungen hat das auch nichts zu tun. Ich habe beruflich mit Leitsystemen zu tun, das ist eine andere Liga. Es gibt auch genügend Webanwendungen mit hunderten ständig wechselnden Datenpunkten. Das machen die Rechner und Browser schon mit.
Ich habe das leise Gefühl, dass es hier weiterhin ein Memory-Leak bzw. unsaubere garbage-collection Routinen von externen Bibliotheken gibt, da die Views direkt nach dem Laden für Minuten stabil und performant sind. Wenn dann im Laufe der Zeit die Performance runtergeht, deutet das alles auf zu lange Listen, die für Aktualisierungen etc. durchsucht werden müssen.Ich denke, dann werde ich mal (leider) zusätzliche längerzyklische Datenpunkte verwenden und das testen...
Wie ich javascript in der View verwenden kann, weiß ich leider (noch) nicht.@crunchip die queries für den javascript-adapter kenne ich. Ich meinte eher, dass ich die in der VIS irgendwie benutzen kann.
-
@seb2010 prinzipiell stellt sich die Frage welche WebView Version auf den Geräten läuft. Je älter diese ist umso mehr Probleme kann es natürlich geben. Samsung Tab A7 hat zwar 4GB Ram aber ist trotzdem schon etwas in die Jahre gekommen und welche WebView darauf läuft - keine Ahnung - aber maybe liegt es daran.
Meine Einschätzung. -
@seb2010
Wenn du das html Widget verwendest dann trägst du da deine datenpunkte per Binding ein.
Binding ist sehr ineffizient umgesetzt.
Die Verwendung von Widget ist effizienter -
@seb2010 aber du weisst schon dass das Frontend alles rendert?
Deswegen ist die Frage / Hinweis auf@liv-in-sky sagte in Object Binding + viele Aktualisierung -> View extrem langsam:
eine performante maschine
durchaus berechtigt.
Insbesondere wenn du jetzt auch noch@seb2010 sagte in Object Binding + viele Aktualisierung -> View extrem langsam:
die Energieflüsse darstellen
darstellen willst, womöglich animiert.
-
@djmarc75 Auf dem Tab läuft Android 12 mit der allerneusten WebView. Das ist es leider nicht. Ist sonst auch total nackt. Ich muss mich glaube ich mal in das Widget-Developement einlesen...
-
@homoran ja schon, aber was heißt denn hier renden? Wir stellen doch "nur" eine Webpage dar. Das der innerHTML Inhalt dann mal ausgetauscht wird ist doch der absolute Standard. Da ist jeder einzelne der 47 Werbebanner auf Webpages aufwändiger als das zu rendernde HTML Object. Und so ne billige SVG-Linie mit Animation wird ein Tablet das nicht steinalt ist ja wohl auch hinbekommen.
Wie gesagt, in den ersten paar Minuten läuft auch alles flüssig, was bedeutet dass die Performance reicht. Wenn es über die Zeit langsamer wird, werden irgendwelche Datenobjekte zu komplex. Wenn das Widgets abfangen können, bin ich dabei. -
nochmal - wieviel browseranwendungen kennst du, die mehrfach pro sekunde daten holen und anzeigen ? dein cache und browser kann das nicht richtig handhaben - deshalb dauert es ein wenig, bis das ganze zum problem wird - reload der seite und es funktioniert wieder für eine zeit - ich denke, es ist ein browser thema
-
@liv-in-sky Lass uns doch mal nicht darüber diskutieren, ob es das jetzt gibt oder nicht. Ich komme aus dem Stromhandelbereich und da gibt es viele Web-Anwendungen die viele Daten der Börsen und Windparks mindestens alle Sekunde aktualisieren.
Die Frage ist doch eher, wie kann man die Performance in der Art der Anwendung steigern. Ich kann zwar im Prinzip HTML und javascript, aber in der Webprogrammierung bin ich nicht so tief drin. Ich sehe aber bspw. in den Dev-Tools, dass ein VIS-Objekt bei inline-Datenaktualisierung immer komplett neu aufgebaut wird. Könnte man nicht irgendwie erreichen, das wirklich nur der Variablen-Wert im HTML des Objekts geändert wird? Man muss dann doch "nur" dem Textabschnitt eine ID geben und bei diesem dann gezielt den Text austauschen...
-
@seb2010 sagte in Object Binding + viele Aktualisierung -> View extrem langsam:
dass ein VIS-Objekt bei inline-Datenaktualisierung immer komplett neu aufgebaut wird
das ist das gemeinte rendern!
Bei Grafana weiß ich nicht ob da ein serverside rendering existiert, aber dann wiederum wäre es ein hohercDatentransfer. -
Also ich habe jetzt mal diese Methode probiert:
Das HTML-Widget bekommt als javascript bspw. folgendes:const myTimeout = setInterval(updateValue, 1000); function updateValue() { $.ajax({url: "http://addresse:8082/getPlainValue/javascript.0.Strom.ConsumptionOnInputL2power", success: function(result){ $("#TextID").html(result); }}); }
wobei TextID in dem HTML-Code des Widgets die ID des den Wert umschließenden DIVs ist. Ist das die Lösung die hier angesagt wäre? Ich sehe dabei keinen Neuaufbau des Objekts, sondern nur eben das der HTML-Teil geändert wird. Ehrlich gesagt würde ich mir so die Inline-Datenaktualisierung wünschen. Vermutlich verbaut man sich damit den Weg für die höherwertigen Javascript-Operationen.
Laufe ich damit in Folgeprobleme?
-
habe ich im ersten post geschrieben - mit einem jquery script ist das wohl möglich in einem html widget - aber auch dort musst du dann ein interval einstellen, wie oft du die daten holen willst - dann kannst du nicht mehr getriggert durch den datenpunkt werden
hier ein beispiel mit innerhtml - geht auch mit jquery
<div id="test12" class12="class1">Test mit Datenabfrage:</div> <div id="test1" class="class12">14</div> <div id="test13" class="class13">14</div> <script> var test = document.getElementById("test"); var testClass = test.className; console.log(test.className); console.log(test.getAttribute('class')); setInterval(function(){ Self.servConn.getStates(['0_userdata.0.CONTROL-OWN.AAATEST.TestZahl2'], (error, states) => { test1.innerHTML = states['0_userdata.0.CONTROL-OWN.AAATEST.TestZahl2'].val; $("#test13").html(states['0_userdata.0.CONTROL-OWN.AAATEST.TestZahl2'].val); /*mitjQuery*/ } ); }, 1000) </script>
mache so was ähnliches mit anderen daten
-
ahh - da hast du doch deine lösung schon selbst gefunden
-
@seb2010 sagte in Object Binding + viele Aktualisierung -> View extrem langsam:
Vermutlich verbaut man sich damit den Weg für die höherwertigen Javascript-Operationen.
denke nicht
-
@liv-in-sky super, danke dir!
-
@seb2010
Mit dein letzten Beispiel startest du mit jeder Abfrage einen eigenen request. Wenn du sehr viele Daten abfragst, dann startest du sehr viele request. Außerdem hast du das pull Prinzip, also Daten werden erneut abgefragt, die sich nicht geändert haben.
Das wären die Probleme die ggfs auf dich zukommen könnten.Um auf meinen Post oben nochmal im Detail einzugehen.
Vis nutzt socketio zur Kommunikation mit dem Server. Dafür wird eine kontinuierliche websocket Verbindung aufgebaut. Der Server informiert alle angemeldeten. Clients über alle geänderten datenpunkte, welche auch vom Client abonniert wurden.
Sofern ist schonmal eine effiziente Grundlage da.
Wie oben schon erwähnt ist das Problem das binding.
Für jeden bindingplatzhalter muss bei jeder Änderung der komplette widgetinhalt neu aufgebaut werden.
Wenn du jetzt in einem Widget umfangreich html mit mehreren datenpunkten hast die sich dann auch nochmal mehrmals die Sekunde ändern können, dann wird der widgetinhalt auch mehrfach pro Sekunde komplett neu aufgebaut.
Aufgrund der zusätzlichen Operationen, die in einem binding mit angegeben werden können, macht die Interpretation und Berechnung auch nicht einfacher.Wenn du das mit den ht,l Widgets beibehalten willst, dann könntest du einen eigenen Aktualisierung Code schreiben.
Dafür müsstest du dafür sorgen, das alle notwendigen datenpunkte durch vis abonniert werden. Dann stehen alle Daten im Array vis.states
Das ist allerdings kein normales Array, sondern ein ein Array mit canjs Objekten https://v2.canjs.com/docs/can.Map.html
Darauf kann man einen observer setzen, der ein informiert wenn vis/socketio die Daten aktualisiert -
@oliverio Jeeeesus! Das muss ich mir mal in Ruhe ansehen. Jetzt läuft es erstmal mit nem 10s Interval.
Mal sehen ob damit die View ächzt.