[gelöst] Object Binding+viele Aktualisierung=View langsam

[seb2010]

@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.

[liv-in-sky]

@seb2010

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

[seb2010]

@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...

[Homoran]

@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.

[seb2010]

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?

[liv-in-sky]

@seb2010

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

[liv-in-sky]

@seb2010

ahh - da hast du doch deine lösung schon selbst gefunden

[liv-in-sky]

@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

[seb2010]

@liv-in-sky super, danke dir!

[OliverIO]

@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

[seb2010]

@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.