Performance

[Chris M.]

Um saubere Infos über die Performance der CometVisu zu bekommen habe ich gerade eine Instrumentierung eingebaut. Um diese zu Nutzen muss man an die URL den Parameter "profile" anhängen.
Wenn man das Ergebnis nicht auf der Console sehen möchte (z.B. auf mobilen Geräten), kann man dem Parameter noch den Wert hidden anhängen (also profile=hidden). Um dann den Wert zu sehen, muss man den JavaScript Befehl

profileCV('list')

ausführen.
(Da das auf mobilen Geräten natürlich auch doof ist, kann man sich leicht behelfen - man erweitert die Statusbar um <a href="javascript: profileCV('list')">Show Profile</a>.)

Um nun über Performance sprechen zu können, muss man erst mal definieren, was es da überhaupt für relevante Größen gibt und wo welcher Fokus liegt. Grob könnte man beispielsweise unterteilen in:

1. Ladezeit - Seitenaufruf bis die (statischen) Daten intern vorliegen
2. Aufbauzeit - bis die Struktur (Widgets) dargestellt sind, die dynamischen Werte vom Bus sind noch nicht vorhanden
3. Darstellzeit - bis auch die Werte in den Widgets stehen
4. Wechselzeit - Dauer vom Klick bis zur Darstellung der neuen Seite
5. Sendezeit - Dauer vom User-Klick bis zum KNX Telegramm
6. Updatezeit - Dauer vom KNX-Telegramm bis zur Darstellung des neuen Wertes im Widget

Hier sollte klar sein, dass 1.-3. unmittelbar aufeinander folgen und vom User unabhängig sind.
4. ist reine User-Interaktion und nur vom Browser abhängig.
5. und 6. braucht den Bus dazu.


Auch wenn ich versucht habe überall geschickte Algorithmen zu wählen, hatte ich bisher noch nicht viel Aufwand in Optimierungen gesteckt (ganz im Sinne von Knuth). Und Optimierungen ohne Messungen sind wertlos - daher das Commit zur Revision #2339 (wobei sich die Instrumentierung im wesentlichen auf 1.-3. bezieht)


Hintergrund: Meine Philosophie hinter der aktuellen Struktur war, dass ich Compile-Time vor Setup-Time und Setup-Time vor Run-Time bevorzuge. D.h. alles was man offline (also Compile-Time) lösen kann, wird dort gelöst. (Bei einer Online-App schwierig... Aber das wird zum einen im Build-Prozess durch das Minimizen gemacht, zum anderen mit dem Appcache, der als Nachteil uns somit beim Entwickeln nervt - aber dafür den Nutzern mit deutlich geringerer Datenübertragung hilft).
Und was wir zur Setup-Time (etwas 1. und v.a. 2.) machen können, machen wir dort. Um einfach keine Ressourcen bei 3. und 4. dafür verwenden zu müssen - daher laden wir nicht jede Seite neu, wie manche anderen Visus.

=> Wenn man nun irgendwo Performance Probleme spürt, bitte diese klar benennen (z.B. nach der obigen Liste). Und wenn es um eines der Themen 1., 2. oder 3. geht, dann bitte auch die Profiling-Instrumentierung nutzen um der Diskussion ein paar Fakten beizusteuern.

So, ich geht jetzt mal etwas 2. zu optimieren. Das braucht viel länger als nötig...

[XueSheng]

Chris, ich finde super, dass Du Dich dem Thema Optimierung widmest.

Sind denn die Werte von profileCV als solches überhaupt hilfreich? Fehlen dann nicht noch Angaben zur Anzahl GAs und Komplexität der Visu (Anzahl Widget, Plugins, etc.).???

Bzgl. Performance merke ich deutliche Unterschiede zwischen Desktop und Smartphone, daher nachfolgend getrennte Betrachtung:

1. Desktop:
   Insgesamt ausreichende Performance. Ladezeit bis Abschluss Aufbauzeit könnte etwas schneller sein. Subpages werden flott geladen. Buswerte sind auch zügig zu sehen (solange im Cache vorhanden). Eigentlich alles nicht so wild, weil: die Visu wird einmal bei PC/Browser-Start geladen und gut ist's.
   profileCV:
   

   "49.911507 (- ms): JavaScript start
   337.854749 (287.94324200000005 ms): templateEngine start
   381.965948 (44.111199 ms): parseXML
   439.598855 (57.63290699999999 ms): setup_page start
   528.059032 (88.46017699999999 ms): setup_page start
   616.712307 (88.65327500000001 ms): setup_page start
   616.772864 (0.06055700000001707 ms): setup_page running
   2577.083816 (1960.3109519999998 ms): setup_page created pages
   3229.805627 (652.7218110000003 ms): setup_page finish
   5841.080808 (2611.2751809999995 ms): firstdata start
   8418.318281 (2577.237473 ms): firstdata updated
   "

2. Smartphone (im heimischen WLAN)
   Die Ladezeiten sind hier deutlich zu lang. Die Werte des profileCV kann ich jetzt nicht direkt zuordnen, aber die Zeit bis zum Aufbau der Visu (ohne Buswerte) liegt bei ca. 20 Sekunden. Bis Darstellung Buswerte nochmals ca. 10 Sekunden (Werte großzügig gerundet). Hauptproblem ist hierbei, dass die Visu ständig neugeladen werden muss, wenn man mal eine andere App als den Browser verwendet (Speichermanagement bei Android ist so ne Sache für sich). Daher ist der WAF gleich Null (mal eben die Visu auf dem Smartphone öffnen geht nicht).
   
   provileCV Text kann leider auf dem Smartphone nicht kopiert werden, daher angefügt das zusammengestückelte jpg.

[Chris M.]

Sind denn die Werte von profileCV als solches überhaupt hilfreich? Fehlen dann nicht noch Angaben zur Anzahl GAs und Komplexität der Visu (Anzahl Widget, Plugins, etc.).???

Jain. Im konkreten Fall ist das natürlich wichtig - aber alleine die beiden Auszüge, die Du gepostet hast sind schon sehr interessant. Auch schon wegen dem Quervergleich Desktop<->Mobil

Desktop:
Insgesamt ausreichende Performance. Ladezeit bis Abschluss Aufbauzeit könnte etwas schneller sein.
[...]

2577.083816 (1960.3109519999998 ms): setup_page created pages
3229.805627 (652.7218110000003 ms): setup_page finish
5841.080808 (2611.2751809999995 ms): firstdata start
8418.318281 (2577.237473 ms): firstdata updated

-> fast 2 Sekunden bis das HTML / DOM der Seite aufgebaut wird - geht gar nicht. Da hab ich hoffentlich schon eine Idee
-> 2.6 sec bis Daten angekommen sind. Woran liegt das?!?
-> 2.5 sec bis die Widgets auf Wert gebracht wurden ist auch nicht schön

Smartphone (im heimischen WLAN)
Die Ladezeiten sind hier deutlich zu lang. Die Werte des profileCV kann ich jetzt nicht direkt zuordnen, aber die Zeit bis zum Aufbau der Visu (ohne Buswerte) liegt bei ca. 20 Sekunden. Bis Darstellung Buswerte nochmals ca. 10 Sekunden (Werte großzügig gerundet).

14 Sekunden bis die Seite steht - noch schlimmer, das muss deutlich schneller gehen!
Danach noch mal 6 Sekunden aufräumen?!?
1 Sekunde bis Daten da sind - im Vergleich zum Rest geht das schon fast...
Dann nochmal 11 Sekunden bis die Widgets aktuallisiert wurden...

Neben dem allgemeinen Optimierungsbedarf verstehe ich nun etwas besser woher das (gefühlte) Problem des langsamen Daten-Ladens kommt: die Daten sind zwar vernünfig da, aber durch das Updaten von allen Widgets dauert es halt lange bis man was sieht.
Da hilft dann natürlich das initiale Laden (was eigentlich für die Tonne ist, da noch nicht auf Index-Laden umgestellt werden kann), da die paar Startseiten-Widgets natürlich deutlich schneller aktuallisiert sind.

[mivola]

So,

hier nun meine Performance-Messung.

Erstmal ein paar Worte zur Umgebung:
- Chromium 41.0 auf Core i7
- CV läuft auf Wiregate
- Verbindung zu WG/CV via VPN (DSL 6000)

 ### Profile ###: 50.5700000003344 (- ms): JavaScript start
 ### Profile ###: 231.839000000036 (181.26899999970192 ms): templateEngine start
 ### Profile ###: 513.244000000668 (281.40500000063184 ms): parseXML
 ### Profile ###: 536.549000000377 (23.304999999709253 ms): setup_page start
 ### Profile ###: 573.15700000072 (36.608000000342145 ms): setup_page start
 ### Profile ###: 582.55200000076 (9.395000000040454 ms): setup_page start
 ### Profile ###: 582.910000000084 (0.35799999932351056 ms): setup_page running
 ### Profile ###: 1189.52500000069 (606.6150000006019 ms): setup_page created pages
 ### Profile ###: 1376.79200000002 (187.2669999993377 ms): setup_page finish
 ### Profile ###: 22664.9670000006 (21288.175000000592 ms): firstdata start
 ### Profile ###: 22964.0660000005 (299.0989999998419 ms): firstdata updated

Bis zu setup_page gehts eigentlich ganz flott - danach kommt eine große Pause und danach werden die Werte der Widgets angezeigt. Das ist (für mich) eigentlich auch der einzige Kritikpunkt. Mit dem Rest kann ich prima leben ...

VG
Micha

[Fry]

Was nehmt ihr eigentlich so auf Android-Tablets für optimale Performance? Welcher Browser, spezielle Einstellungen, Kiosk-Mode?
VG, Fry

[NilsS]

zum anderen mit dem Appcache, der als Nachteil uns somit beim Entwickeln nervt - aber dafür den Nutzern mit deutlich geringerer Datenübertragung hilft).

Habt ihr Interesse da etwas gemeinsames mit xxAPI² und evtl auch anderen Visu's zu finden?

Das Problem des Appcache ist unter anderem ja nicht nur das der halt auch beim Entwickeln stört, sondern auch das man keine Wildcards in der Cache Sektion verwenden kann um die Bilder zu cachen.

LocalStorage scheidet aufgrund der 5MB Grenze auch aus, daher bleibt eigentlich nur IndexDB oder WebSQL (eher nicht weil tot) oder ein Framework wie PouchDB darüber.

ft.com hat da einige interessante Dinge. Tutorial 2: Supporting both IndexedDB and WebSQL on a cross platform web app | FT Labs vielleicht könnte man ja die Sahnestückchen davon in ein oder zwei Funktionen packen die unsere Probleme lösen.

[Chris M.]

Was nehmt ihr eigentlich so auf Android-Tablets für optimale Performance? Welcher Browser, spezielle Einstellungen, Kiosk-Mode?

Anspruch: Der Stock-Browser sollte ziemlich optimal funktionieren - einfach weil den die meisten haben.

Praktisch ist das auch der Fall. Ich hab bei meinen Android-Geräten mit dem Stock-Chrome (nicht die seltsame, veraltete Samsung Interpretation...) keine Probleme. Im Gegenteil, Chrome hat zu recht einen guten Ruf! (Parallel hab ich noch einen Firefox drauf um per AdBlock in Ruhe surfen zu können...)

Spezielle Einstellungen sollten auch nicht benötigt werden (-> Anspruch).
Und für den Kiosk-Mode gibt's seit kurzem eine ganz praktische Möglichkeit: https://knx-user-forum.de/cometvisu/...omescreen.html
(Ja ging auch vorher, so ist's aber ganz offiziell unterstützt und von Google gewünscht...)

Alternativ gibt's ja noch die App: https://knx-user-forum.de/cometvisu/...r-android.html

Habt ihr Interesse da etwas gemeinsames mit xxAPI² und evtl auch anderen Visu's zu finden?

Ich hätte auch Interesse daran, dass der HomeServer das CometVisu-Protokoll spricht

Davon unabhängig: ja, wir haben in Teilen die gleichen Probleme zu lösen. Da kann man gerne gemeinsame Lösungen suchen.

Das Problem des Appcache ist unter anderem ja nicht nur das der halt auch beim Entwickeln stört, sondern auch das man keine Wildcards in der Cache Sektion verwenden kann um die Bilder zu cachen.

Man kann den im Zweifel auch per Script generieren...
Bei den Icons ist aber das Problem, dass die in lauter Einzeldateien vorliegen. Hier sollten diese ultimativ wohl mal in einer Datei zusammengefasst werden.
Oder besser, eine SVG genommen werden (das letzte mal als ich geschaut hatte, also vor ein paar Jahren, konnten leider noch nicht alle wichtigen Plattformen SVGs darstellen...)

ft.com hat da einige interessante Dinge. Tutorial 2: Supporting both IndexedDB and WebSQL on a cross platform web app | FT Labs vielleicht könnte man ja die Sahnestückchen davon in ein oder zwei Funktionen packen die unsere Probleme lösen.

Schau ich mir gerne mal an.

Noch hab ich den Fokus auf das schnelle generieren des DOM Tree gelegt. Icons die nachgeladen werden laufen ja dazu parallel.
Aber mittelfristig sollte auch das optimiert werden, da gebe ich dir absolut Recht.

[makki]

14 Sekunden bis die Seite steht - noch schlimmer, das muss deutlich schneller gehen!
Danach noch mal 6 Sekunden aufräumen?!?

Ich glaube ich hatte den Ansatz schonmal erwähnt:
- (eib)r(ead) ist nicht das Problem, sondern Widgets und Grafiken (diagram); diese sollten erst geladen werden, wenn der Rest fertig ist.

Makki