Browser Performance mit VIS stark beansprucht
-
Hallo Jens,
@jens.maus:wurde dann aber auf diesen hier verwiesen. `
Ist schön wenn alles zusammen in einem Thread steht, aber so war das nicht gemeint. Nur ob hier vielleicht Infos für dich drin stehen.das die Statusänderungen eben leider nicht mehr instantan dargestellt werden sondern mitunter bis zu 10 sek vergehen können bis die geöffnete Tür entsprechend dargestellt wird. `
Dieses Phänomen für sich ist nicht bekannt.Wie sehen denn die anderen Visualisierungen aus? (z.B. Temperatur o.a., das cyklisch geloggt wird und nicht auf Änderungen angewiesen ist?
Oder Charts?
Ist alles quälend langsam? Auch das Umschalten von views?
So etwas ist bekannt.
Bisher habe ich den Eindruck, dass die Ursache tatsächlich auf das Frontend einzugrenzen ist. Allerdings sollte ein iPad (RAM?) doch einiges schaffen.
@jens.maus:Lade ich zwischendrin die VIS Seite komplett neu wird der status sofort mit dem korrekten Statuswert dargestellt. `
Das deutet nicht auf zu schwache Hardware, eher tatsächlich in die Richtung immer stärker eingreifende Stromsparsysteme, bei iPad schon früher, bei Android in den letzten Versionen.man das Problem nicht wirklich zu fassen bekommt. Würde ja auch gerne selbst das ganze irgendwie tiefer Debuggen wollen, aber leider fehlt mir da bisschen irgendwo der Ansatzpunkt. `
So geht es mir auch, vielleicht schaffen wir es ja gemeinsam.Gruß
Rainer
-
das die Statusänderungen eben leider nicht mehr instantan dargestellt werden sondern mitunter bis zu 10 sek vergehen können bis die geöffnete Tür entsprechend dargestellt wird.
Dieses Phänomen für sich ist nicht bekannt.Jens hat es exakt beschrieben. Genau so ist es auch bei mir! Türstatus stark verzögert, bei mir lasse ich Display ausgehen, resync 1-2Minuten, usw. ich wiederhole jetzt nicht alles.
Ich habe auch eine Menge Widgets gelöscht (z. B. Camera Widgets).
Meine Zusammenfassung zuvor war NICHT auf dem Tablet, sondern auf dem PC mittels Google Devoloperhelp. WLAN lasse ich außen vor.
Und ich möchte noch mal erwähnen, dass auch meine PC Browser zusammenbrechen! Lasse ich diese eine Weile auf (meist mit vis und/oder admin), dann werden diese quälend langsam - auch auf anderen Webseiten! Der PC ist aber nicht ausgelastet.
Ich kann es drehen wie ich will, es liegt meiner Meinung nach am Browser - besser gesagt am geladenen Inhalt. Daher auch meine Auswertung weiter oben.
<u>Die Fakten aus meiner Sicht:</u>
-
Android,
-
iPad,
-
PC Browser mit Firefox…
-
… und Chrome zeigen identische oder ähnliche Probleme mit der Performance nur innerhalb des Browsers.
Auf Tablet oder PC arbeiten die anderen Tasks (z. B. FTP und SayitAusgabe via Mediaplayer24) zeitnah und schnell, auch wenn der Browser .vis quälend langsam anzeigt.
-
-
Ich kann es drehen wie ich will, es liegt meiner Meinung nach am Browser - besser gesagt am geladenen Inhalt. Daher auch meine Auswertung weiter oben. `
Auch ich denke es liegt in der Tat an dem was der Browser an Javascript von VIS zur Abarbeitung bekommt. Gerade bei größeren VIS Umgebungen kann die menge des Javascript ja schon sehr rasant und stark ansteigen. Trotzdem denke ich müssten eigentlich moderne Browserengines damit recht gut und performant klar kommen. Deshalb vermute ich immer noch das irgendwo in VIS ein bottleneck bzw. bug existiert das die Browser alle in die Knie gehen lässt weil irgendwelche Javascript Funktionen vermehrt aufgerufen werden. Denn auch hier passiert es z.B. auf meinem Linux server (intel NUC i5) das dort der Firefox konstant 100% CPU Last macht sobald ich die VIS seite eine weile darstellen lasse.
Ich denke man bzw. Bluefox wird ggf. nicht drumrum kommen hier ein detailliertes Debugging der gesamten Javascript Mechanismen in VIS zu tätigen. Ich selbst bin zwar kein Javascript Entwickler, aber ich habe hier im Firefox z.B. einfach mal kurzerhand mit F12 den Debugger bzw. die Performance-Messengine angeworfen und einfach mal die funktionsaufrufe in VIS im Leerlauf mitaufnehmen lassen. Und ich kann da z.B. erkennen, dass bei mir mehr als 50% der Zeit VIS damit verbringt konstant "_setTimeout()" in vis.js nacheinander aufzurufen. Vielleicht kann der Eine oder andere das ja mal versuchen zu reproduzieren.
-
Und ich kann da z.B. erkennen, dass bei mir mehr als 50% der Zeit VIS damit verbringt konstant "_setTimeout()" in vis.js nacheinander aufzurufen. Vielleicht kann der Eine oder andere das ja mal versuchen zu reproduzieren. `
Hatte ich nicht so gefunden - wo hast Du es wie gesehen?Ich stelle gerade nur fest, dass der Speicher immer weiter, lamgsam, zuläuft. Habe nur vis in Ruhe im Taskmanager beobachtet. Langsam aber stetig steigt es, dann fällt es mal wieder ein bischen, dann steigt es wieder. Im Mittel verzeichne ich einen positiven Anstieg. Das wäre auch eine Erklärung. Im moment suche ich noch nach Mitteln, wie ich herausfinde, was da genau den Speicher benötigt… Watson - übernehmen Sie...
-
Redet ihr von dem Speicher des Front Ende oder vom Server?
Gruß
Rainer
-
Redet ihr von dem Speicher des Front Ende oder vom Server? `
Wir reden from Frontend der im jeweiligen Browser läuft. All die Symptome die ich/wir hier sehen deuten eigentlich sehr stark darauf hin das irgendetwas mit dem Frontend nicht stimmt und dafür verantwortlich ist das es über längere Zeit immer langsamer wird bzw. Updates nicht instantan passieren und man fast regelmäßig die Verbindung zu VIS komplett neu starten muss.
-
Schönes Beispiel am PC. Habe heute so um die 6h .vis und admin offen gelassen. Und auch andere Sachen dann im Browser gemacht. Z. B. das Forum genervt oder ioBroker Skripte zu schreiben versucht.
Nach einiger Zeit war der Firefox träge, bei allen JS-Dingen. So schlimm, dass z. B. der rechte Forums-EineIdee Button einfach nicht mehr ging! Das hing genauso wie auf dem Tablet vis träge ist.
Erst ein Neustart des Rechners half auf die Schnelle, wobei ich nicht probierte, den schuldigen Task zu finden.
Wenn ich aber wie gestern den ganzen Tag was anderes online mit JavaScript im Firefox am selben Rechner in der gleichen Umgebung programmiere (z. B. ein JS-Spiel mit canvas Technik), passiert das nicht.
Also einwandfrei das FrontEnd.
-
Hallo,
das hier geschilderte Verhalten der immer träger reagierenden vis-Views stelle ich in entsprechender Weise auch bei der ioBroker.vis App für Android fest. Bringt diese einen eigenen Browser mit, oder warum verhält sie sich vergleichbar?
Übrigens, ioBroker selbst läuft auf meinem Raspi 3 nach wie vor flüssig und schnell. Wenn ich z.B. eine Anfrage über den Telegram- und den text2command-Adapter an ioBroker sende, erhalte ich umgehend eine Rückantwort. Auch Flot reagiert in Verbindung mit MariaDB auf meiner DiskStation immer noch sehr schnell und verzögerungsfrei.
Bis dann,
Thorsten
-
Nur ein paar Punkte!
Ich Kann nicht beurteilen ob da Zusammenhänge existieren.
Heute gab es bei mir ein Android Update beim System Webview.
Wenn euer "Display" langsam wird, geht dann die Load auf em raspi hoch?
Wenn nicht, haben wir verschiedene Probleme.
Gruß
Rainer
-
Hallo zusammen,
da hier ja auch das Performance Thema für die App behandelt wird, möchte ich da einhaken.
Ich habe ähnliche Erfahrungen gemacht, daß nach Neustart der App alles flüssig läuft. Der Doppelpunkt in der Uhrzeit blinkt im Sekundentakt, Rückmeldungen über geöffnete Fenster oder Türen erscheinen sofort, Betätigung von Schaltflächen Navigieren oder auch Schalten von Aktoren erfolgt flüssig.
Das wird leider mit der Zeit immer schlechter und unperformanter. => Es treten Latenzzeiten bei allen Aktionen auf.
Bei mir läuft die App auf einem Galaxy Tab4 an der Wand. Hier ist mir auch ein weiterer Punkt aufgefallen: Mit der schlechter werdenden Performance steigt anscheinend auch der Energiehunger der App. Das führt sogar dazu, daß trotz Ladevorgangs die Batteriekapazität weiter in den Keller geht?! :?:
Nach Neustart der App tritt das üblicherweise nicht mehr auf. :? Lässt sich auch am Ladebildschirm des Tablets erkennen, da erscheint die App dann ganz oben bei den Energieverbrauchern noch über dem Bildschirm! :?:
So ein Verhalten kannte ich bislang (DashUI) nicht. Kennt das sonst noch jemand? Oder liegt das an meiner Hardware? :oops:
Gruß
Torsten
-
Hi, ich habe auch das Browserproblem auf meinem Cytem 14 Zoll Tablet.
Nach einer gewissen Laufzeit des Browsers, wird alles so richtig zäh. Irgendwann schmiert dann der Browser ab.
Gruss, mayer
-
Nach einer gewissen Laufzeit des Browsers, wird alles so richtig zäh. Irgendwann schmiert dann der Browser ab. `
Das alles hört sich wirklich danach an das da wohl ein generelles Problem mit der Javascript-Umgebung existiert die VIS an den Browser sendet. Inzwischen liegen ja reports vor das das nicht nur mit iPads und Android Tablets passiert. Auch Desktop-Browser wie Firefox scheinen davon betroffen zu sein. Meine Vermutung ist das da irgendetwas mit der Zeit dazu führt das immer mehr Speicher & CPU verbraucht wird im Browser im dem VIS dargestellt wird. Mit meinen geringen Javascript Kenntnissen weiss ich ehrlich gesagt nicht wie ich das ganze genauer analysieren soll. Ich denke hier müsste definitiv jemand mal Bluefox drauf ansetzen das er versucht das gleiche zu reproduzieren und dann entsprechend versuchen das Problem einzugrenzen.
-
Zu der geschilderten Problematik möchte ich meine Erfahrungen einbringen. Ich habe ein Ipad2 in der Wand. Dort wird vis angezeigt. Ich habe meinen Startscreen nun 3 Stunden durchgehend laufen lassen. Ich könnte keinerlei Performanceveränderung feststellen. Auch nach den 3 Stunden blinkte die Zeit wie nach dem einschalten. Ein öffnen der Balkontüre wurde sofort angezeigt. (Magnetischer Türkontakt). Ich betreibe iobroker allerdings nicht auf einem Raspi, sonder auf einem W10 Rechner mit einer 2.3 GHz. Celeron CPU und 4GB RAM. Evt. hat die Leistung des Hosts auch etwas mit dem Problem zu tun.
-
Evt. hat die Leistung des Hosts auch etwas mit dem Problem zu tun. `
Den Verdacht habe ich auch, bei mir sogar nahezu gesichert.Deswegen hatte ich ja gefragt:
@Homoran:Wenn euer "Display" langsam wird, geht dann die Load auf dem raspi hoch? `
Gruß
Rainer
-
[…]Ich betreibe iobroker allerdings nicht auf einem Raspi, sonder auf einem W10 Rechner mit einer 2.3 GHz. Celeron CPU und 4GB RAM. Evt. hat die Leistung des Hosts auch etwas mit dem Problem zu tun. `
Ganz sicher kann/wird das auch teilweise der Fall sein. Allerdings betreibe ich mein ioBroker auch nicht auf einem Rapsi sondern auf einem intel NUC i5 (QuadCore i5-4250U) mit 16GB RAM. Ich kann mir also schwer vorstellen das die NUC hier auch nur annähernd ausgelastet sein soll. Ich kann auch kein wesentlichen unterscheid im Load feststellen wenn meine Frontend-Probleme auftreten.
-
Hi,
ich habe vor eininger Zeit ein ähnliches Problem gemeldet
http://forum.iobroker.net/viewtopic.php?f=22&t=3296
Ich bin mir nicht ganz sicher ob es evt. die hier geschilderten Probleme trifft.
Das Verhalten meiner Frontends scheinen etwas unterschiedlich zu sein.
-
nach ein paar Minuten aktualisieren überhaupt keine states mehr
-
Schalten funktioniert noch. Allerdings mit schlechter Reaktionszeit der geschalteten Verbraucher
-
Getestet habe ich iobroker app, boat browser kiosk browser, chrome am Galaxy 4 Tab
Das Frontend selber als Problem schliesse ich aus. Gleiches Verhalten zeigt sich nämlich beim Phone Galaxy S7
und das hat genügend performance.
Mein PC läuft i.d.R. sehr performant mit VIS.
Ich habe schon einige Adapter rausgeschmissen. keine history (war ein performance killer) mehr etc. ca. 20 Adapter laufen
Alles ist up to date . In der Verzweiflung habe ich sogar Jessie und Node 4.x installiert und auch mein Galaxy Tab auf android 5.x gebracht.
Hat aber alles nix geholfen.
Ich habe 1 Projekt aufgemacht mit abgespeckten views im Vergleich zum MAIN projekt (eben für das TAB)
Ich meine, dass die Probleme erst aufgetreten sind als ich Views in das neue Projekt kopiert habe (wegen der App)
Vorher lief mit dem Main projekt alles solala, allerdings waren die views für auf das TAB nicht gut geeignet.
Vielleicht ist das ein Hinweis ?
vG Looxer
-
-
Zu der geschilderten Problematik möchte ich meine Erfahrungen einbringen. Ich habe ein Ipad2 in der Wand. Dort wird vis angezeigt. Ich habe meinen Startscreen nun 3 Stunden durchgehend laufen lassen. Ich könnte keinerlei Performanceveränderung feststellen. Auch nach den 3 Stunden blinkte die Zeit wie nach dem einschalten. Ein öffnen der Balkontüre wurde sofort angezeigt. (Magnetischer Türkontakt). Ich betreibe iobroker allerdings nicht auf einem Raspi, sonder auf einem W10 Rechner mit einer 2.3 GHz. Celeron CPU und 4GB RAM. Evt. hat die Leistung des Hosts auch etwas mit dem Problem zu tun. `
Also ich stelle die Verschlechterung auch erst nach wesentlich längerer Laufzeit fest. Da muss VIS schon 2-3 Tage laufen…
Evt. hat die Leistung des Hosts auch etwas mit dem Problem zu tun. `
Den Verdacht habe ich auch, bei mir sogar nahezu gesichert.Deswegen hatte ich ja gefragt:
@Homoran:Wenn euer "Display" langsam wird, geht dann die Load auf dem raspi hoch?
Kann ich bei mir nicht feststellen. Der Speicher sowie die CPU Load verändert sich hier nicht maßgeblich! :?:
Gruß
Torsten
-
Hallo Zusammen,
[…]Ich betreibe iobroker allerdings nicht auf einem Raspi, sonder auf einem W10 Rechner mit einer 2.3 GHz. Celeron CPU und 4GB RAM. Evt. hat die Leistung des Hosts auch etwas mit dem Problem zu tun. `
Ganz sicher kann/wird das auch teilweise der Fall sein. Allerdings betreibe ich mein ioBroker auch nicht auf einem Rapsi sondern auf einem intel NUC i5 (QuadCore i5-4250U) mit 16GB RAM. Ich kann mir also schwer vorstellen das die NUC hier auch nur annähernd ausgelastet sein soll. Ich kann auch kein wesentlichen unterscheid im Load feststellen wenn meine Frontend-Probleme auftreten. `
Inzwischen bin ich zumindest einen gewissen Schritt weiter. Nach etwas herumspielen mit dem VIS edit modus ist mir aufgefallen das man ja anscheinend für jeden View unter "Tools->Immer rendern" angeben kann ob der jeweilige View anscheinend IMMER gerendert werden soll auch wenn dieser gerade nicht der aktive ist. Nachdem ich diese Option für alle meine Views deaktiviert hatte wurde die VIS Anzeigen merklich schneller bzw. der Browser konnte auch meine default view von VIS schneller öffnen/darstellen. Auch werden der Status verschiedener Komponenten schneller/instantaner dargestellt. Zwar immer noch nicht perfekt schnell/instantan, aber wirklich eine merkliche Besserung.
Kann das jemand versuchen zu reproduzieren und schauen ob das deaktivieren von "Immer rendern" wirklich auch bei anderen einen Benefit gibt?
-
Das sieht ja wieder aus, als ob die Ursache dafür dann doch das Frontend ist.
Das gab es schon bei dashUI, allerdings auf Widget Ebene. Hier könnte man Animation abschalten anwählen. Dies hatte damals eine Menge gebracht.
Bei vis weiss ich gar nicht ob das bei allen Widgets abschaltbar ist.
Dies würde das Frontend von weiteren JavaScript Aktionen entlasten.
Gruß
Rainer
-
hey,
ich habe einen Ubuntu Server laufen, welcher mir beim letzten Update abgeschmiert ist und ich ihn deshalb komplett neu aufsetzen musste.
Vorher hatte ich immer die selben Problem mit der App wie oben beschrieben(gerätselt), nach dem Aufsetzen funktionierte die App ca.24h einwandfrei, schnelle Widgetanzeige, schnelles schalten usw… einfach spitze.
Nach diesen ca 24h begann die App wieder langsam zu werden. Ich habe am Server nichts gemacht, was ich allerdings gemacht habe ist, die App über den App-manager "abzuschießen", dann habe ich den Cache geleert und die App wieder gestartet.
Seit 2-3 Stunden läuft die App wieder einwandfrei.
Ich stelle hier keine Vermutungen an, was da sein könnte, dass überlasse ich den Jungs die sich besser damit auskennen
