erste beta - fronthem, smartVISU (closed, Bitte die Anschlussthreads benutzen)

[bgewehr]

css - Thema, kannst Du eine Verbesserung erstellen?


Gesendet von meinem iPad mit Tapatalk

[HCS]

Der

Code Auswählen Erweitern

style="color: rgb(0, 0, 0);"
würde nicht da nicht hin gehören

Edit: ich meinte "würde nicht da hin gehören"
Doppelt negiert war es dann doch falsch 

[HCS]

Ist es möglich, dass der Treiber bei Wiederverbindung mit FHEM auch direkt einen refresh der Widgets durchführt?

Das funktioniert bei mir wie gewünscht. Nach einem restart von FHEM werden die Werte nach Ablauf des Timers bei einem erfolgreichen reconnect sofort aktualisiert.

Treiber: Sind mit der Zeit viele Seiten im Dom, wird, bei angeschaltetem Cache und Laden der Seiten per AJAX, das aktualisieren der Gads immer träger. Das liegt vermutlich daran, dass vom Treiber zwar nur die gads aktualsiert werden, die sichtbar sind, aber per each das ganze DOM durchsucht wird. Das wird nach spätestens ab 5 Seiten unerträglich und führt sogar irgendwann dazu, dass gads gar nicht mehr aktualsiert werden, weil der Browser sie "verschluckt".

Am performantesten ist SmartVisu eigentlich ohne jeden Cache und vor allem mit data-ajax="false".

Kann ich leider nicht nachvollziehen.
Ich teste auf einem betagten Android 4.2.1 Tablet (Tegra 3 mit 1,3GHz) mit einer Chrome Web-App
Pagecache in SV ist an, jquery DOM-cache auch und data-ajax ist true
Ich navigiere durch alle meine pages hin und her (incl. der 300 GADs Test-page), ohne dass sich die Geschwindigkeit ändert. Bei Rückkehr auf eine page werden die GADs sofort mit den aktuellen Werten aus FHEM aktualisiert.
SV ist eine originale unveränderte Installation (nicht die Mandantenfähige)
Server ist ein CubieTruck, WebServer lighttpd

Auf dem Nexus 5 mit Android 5.0.1 in einer Chrom Web-App ist das auch so, nur schneller und auf dem Laptop sowieso.

Jetzt müssen wir irgendwie herausfinden, wo die Unterschiede sind.
Ich wollte eh noch den Test-Treiber zum Messen fertig machen. Evtl. kann ich dem noch einbauen, dass er die Zeiten der jquery selectors misst, dass wir mal sehen, ob es überhaupt von da kommt.

[marvin78]

Ich teste es mit Nexus 5, Samsung Galaxy Note 2014 10.1 (also sehr schnell) und Laptop. Server ist ein Intel NUC i5. Webserver ist nginx. Apache wurde auch probiert. Der Unterschied ist maximal marginal. Netzwerk ist Gigabit LAN, Wlan n und ac. SmartVisu ist die mandantenfähige Version (ich glaube nicht, dass hier der Unterschied liegt).

Mache ich alles an (data-ajax,DOM-Cache, Twig-Cache (wobei der, wie gesagt, zu vernachlässigen ist)), kann ich das beschriebene Verhalten auf allen Devices reproduzieren. Das Maß ist natürlich immer ein anderes. Ich rede hier übrigens jeweils über den ersten Aufruf der Seiten(n).

Dabei ist zu sagen, dass ich sehr viele gads (etwa 60-70!?) und dementsprechend auch Elemente im Menü habe. Ist der DOM-Cache an, liegen unter umständen bei 10 Seiten 10 Menüs im DOM. Vielleicht macht das den Unterschied!? Fakt ist, dass jQuery each nicht sehr schnell ist. Ich habe das mal Testweise im Treiber durch for ersetzt und dachte zunächst, es würde sich bessern. Wirklich viel brachte das aber nicht. Ich habe dann auch festgestellt, dass das Durchsuchen des DOM gar nicht so lange dauert aber das Aktualisieren dann ewig. Das sieht man auch in der Konsole.

Das mit dem Menü ist übrigens, meiner Ansicht nach, ein klares Defizit von SmartVisu. Besser wäre es, wenn nur der primary Block per AJAX aktualisiert würde. Ich habe schon Versuche gemacht, das anders umzusetzen aber Twig macht mir da einen Strich durch die Rechnung.

Auch das reine Aktualisieren der gads (auf der ersten aller Seiten) geht insgesamt bei mir recht langsam von statten  ( für mein Empfinden in Zeitlupe). Ich kann ein Performance-Problem bei mir anhand keines anderes Tools nachvollziehen. Ich habe auf dem selben Server eine umfangreiche Webapplikation auf Grundlage von Yii laufen die eine sehr gute Performance zeigt. Auch dort werden teilweise Websockets verwendet. Das zeigt mir, dass es nicht an meiner Umgebung liegt.  Auch bei FHEM, welches auch auf dem selben Server liegt, gibt es auch nach Analyse mit apptime keinerlei Probleme. Alles "fluppt" wie geschmiert.

Ich würde doch gerne mal ein Video sehen, wie das normalerweise aussehen müsste oder ob ich einfach verwöhnt bin...

[HCS]

Ich lasse mal ein Kamerateam kommen. 

Messwerte beziehen sich auf das oben beschriebene Tablet.

Habe gerade einige Messungen gemacht. Die bestätigen Deine Beobachtung. Die selects auf dem dom und die Schleife über das Ergebnis brauchen kaum Zeit (ca. 3ms).

Die Zeit bis der

Code Auswählen Erweitern

$(this).trigger('update', [values]);
wieder zurück kommt ist erheblich, das sind pro GAD zwischen 60 und 100 ms

Und genau da wird es blöd. Da laufen all die individuellen update routinen, die in der widget.js für die widgets implementiert sind. Und natürlich die der selbst gebastelten widgets. Gegen die hat man (außer sie zu optimieren) nichts in der Hand, außer es responsive im Hintergrund zu machen.

Ich muss mal noch messen, ob der trigger Aufruf selbst schon so langsam ist oder ob das wirklich die widget update routinen sind.
Aber beim Überfliegen habe ich schon einige gesehen, die unötig oft den DOM immer wieder das Gleiche fragen.

[HCS]

Das sieht ganz nach den eventhandlern mit selectoren aus, die alle an document gehängt sind.
Das ist wohl nicht unbedingt schnell.

Wenn ich testweise im update delegate des basic.float einfach nichts mache, sind die Zeiten kaum besser.
Eigentlich auch logisch, die widgets sind schon recht weit unten, das event muss den ganzen Pfad im DOM hoch bubbeln und ein selector um die events zu filtern ist da auch noch drauf.

Ja, die jquery-Doku sagt es auch:

Attaching many delegated event handlers near the top of the document tree can degrade performance. Each time the event occurs, jQuery must compare all selectors of all attached events of that type to every element in the path from the event target up to the top of the document. For best performance, attach delegated events at a document location as close as possible to the target elements. Avoid excessive use of document or document.body for delegated events on large documents.

Da habe ich mir einen schönen Mist angelacht. Das liegt weit außerhalb des Treibers. Das ist ein generelles SV-Konzept-Topic.
Und dann hängt es wohl nun auch mit davon ab, ob man viele verscheidene widgets hat oder nicht. Und wie tief unten man mit den widgets ist, und, und, und.
Das erklärt auch ein Stück weit die unterschiedlichen Antwortzeiten.
Wenn das dann mit zunehmender Datenmenge evtl. noch logarithmisch abbaut, ...

Falls jemand die geniale Idee hat, was nun angesagt wäre, dann her damit.
Falls jemand das hier widerlegen kann dann auch her damit.

Gute Nacht ...

[marvin78]

Meine Idee hatte ich oben kurz angerissen. Das steht aber dem zugrundleliegenden jQuery-Mobile Konzept entgegen und wäre, selbst, wenn man es umgegssetzt bekäme, nicht updatesicher. Es wäre hilfreich, wenn das Menü nicht jede Mal neu geladen werden müsste, ein Klickt auf einen Menüpunkt aber nur der Inhalt des primary-Blocks aktualisiert. Erste Versuche dazu mit ajaxload und get hatte ich gestern gemacht (ziemlich erfolglos). Hier müsste man wohl die index.php komplett umschreiben bzw. anders gestalten. Leider komme ich mit dem Twig-Konzept in der Tiefe bisher noch überhaupt nicht zurecht und ich habe auch viel zu wenig Zeit, um mich zeitnah noch intensiver damit zu beschäftigen.

[HCS]

Das würde aber auch nur die Symptome lindern (wie das Nonblocking auch) aber nicht das eigentliche Problem beseitigen.

[herrmannj]

die 100ms decken sich mit meinen Messungen recht gut. Und ja, das liegt in sv. Deswegen wundern mich auch marvins Points ein wenig. Sv funktioniert ja ja soweit (mit dieser Struktur) auch weit über fhem hinaus.

@hcs: ich schau mal ob ich mit dem caching thema was erreichen kann. Idee ist es sich die selector und each Läufe zu sparen in dem das widget selbst gecachet wird, also "update" für den driver erreichbar ist ohne über selectoren und each zu gehen.

@marvin: ich finde jetzt Deine 60-70 GADs nicht soviel. Entweder Deine Erwartungshaltung unterscheidet sich oder da ist noch was anderes. Bitte sei doch so nett und mach echt mal Messungen, an die widget Farbe etc bist Du ja auch rangegangen. Oder anders: schau doch mal ob sich ein jungräuliches sv dir gleich verhält. Dazu könntest Du in einen jungfräulichen Verzeichnis (wichtig ohne eigene visu.js und so) widgets (GAD) mit den Namen internal.0, internal.1  usw anlegen - fronthem bedient die automatisch ohne das Du was im Editor einstellen musst.

@Bernd: Danke für die Korrektur in fronthem_controls
vg
jörg

[bgewehr]

Also, klar könnte immer alles noch schneller sein, aber ich finde es mit caching schon recht gut! Ist sicher auch ne Frage der subjektiven Erwartung!

[HCS]

@hcs: ich schau mal ob ich mit dem caching thema was erreichen kann. Idee ist es sich die selector und each Läufe zu sparen in dem das widget selbst gecachet wird, also "update" für den driver erreichbar ist ohne über selectoren und each zu gehen.

Das ist nicht das Problem, siehe meinen post oben. Die Messungen sagen deutlich, dass das Problem die Events sind.

die 100ms decken sich mit meinen Messungen recht gut. Und ja, das liegt in sv. Deswegen wundern mich auch marvins Points ein wenig. Sv funktioniert ja ja soweit (mit dieser Struktur) auch weit über fhem hinaus.

Ja, aber halt langsam. Ich habe gerade mal ein Experiment gemacht, bei dem ich von Treiber aus alle basic.float und basic.value direkt aktualisiere, ohne die trigger.
Das ist beängstigend schnell (auf dem langsamen Tablet) ...
Und ich verwende immer noch die slectoren und each. Nur halt keine events mehr.

@marvin: Kannst Du mal bitte mit dem angehängten Treiber testen?
Der aktualisiert aber nur die basic.float und basic.value.
Mich würde interessieren, ob das bei Dir auch eine dramatische Geschwindigkeitserhöhung bringt.
So ist das zwar keine machbare Lösung, aber ich möchte erst mal sicherstellen, dass das der springende Punkt ist (auch bei Dir)

@All: der angehängte Treiber ist nicht für den normalen Betrieb geeignet. Nicht verwenden.

[HCS]

Bereit für die Oscarverleihung
In der Hauptrolle ein Nexus 5
Die Aktualisierung von 300 GADs, die von FHEM geliefert werden.
Den Seitenwechsel erkennt man am Aufleuchten des Menüpunktes.
Wenn die Scrollerei beginnt, ist das page Update komplett durch.

Nachtrag, bevor sich jetzt jemand über sein System wundert. Das ist mit dem Test-Treiber und die Geschwindigkeit, die ich mir wünche.
Nur der Weg, wie sie SV-Konzept-Verträglich machbar ist, ist noch unklar.

[bgewehr]

Findest Du das jetzt schnell oder langsam?

[HCS]

Findest Du das jetzt schnell oder langsam?

Ich finde es schnell. So macht es Spaß. Das war mit dem Test-Treiber von zwei Posts weiter oben.
Die Geschwindigkeit würde ich mir wünschen.

Die Original-SV-Geschwindigkeit ist um Kategorieren langsamer, so, dass man es benutzen kann aber der Spaß-Faktor fehlt.

[bgewehr]

Ah, OK! Wollte schon sagen, damit kann man doch leben! Kann man denn die delegates tiefer im DOM aufhängen und würde das schon was bringen?