Statii brauchen lange bis sie angezeigt werden

[henfri]

Hallo,

eigentlich bin ich ja mit der SV recht glücklich. Was aber echt nervt ist, dass es recht lange (Sekunden) dauert, bis die Statii auf einer Seite angezeigt werden.
Ich bin fast sicher, dass andere das Problem nicht haben.

Wie kann ich das Problem eingrenzen? Die Hardware (Server, Client) ist recht stark, ich befinde mich im gleichen Netz. Die HTML Seite wird auch schnell geladen. Nur die Icons brauchen lange, bis sie den richtigen Status zeigen. Es kommen dann alle Icons gleichzeitig.

Backend ist sh.py. Group-Cache (knxd) ist aktiv.

Gruß,
Hendrik

[psilo]

Was genau heißt "recht stark" (CPU, RAM)??? welche Browser? Der Aufbau ist sehr JavaScript-lastig, da sollte die JS Engine auch performant sein.

Ist dèr Page-Cache aktiviert - wobei das nichts mit der Websocket-Verbindung zu tun haben sollte.

Wie groß sind die Pages, also wieviele Items enthalten sie so im Schnitt? Hast Du viele Charts? Ich habe bspw. eine Seite auf der alle RTRs, Jalousien etc drauf sind, die braucht auch lange. "normale" Seiten gehen aber sehr schnell.

Wie performant ist die Netzwerk-Infrastruktur? Ist der Server irgendwie geschützt? Laufen auf dem Client irgendwelche Virenscanner?

[henfri]

Moin Psilo,

vielen Dank für deine Antwort.
Der Server ist ein Pentium G3220 @ 3.00GHz mit 20GB Ram. Der Client ein Nexus 5X und ein Core i7 mit jeweils Chrome.
Den Page-Cache habe ich (momentan; hatte ich aber schon, keine Änderung) nicht aktiv, aber die Übertragung der Seite an sich ist ja auch schnell.

Die Seite habe ich mal angehängt. 62 Items und 3 Plots.

Das Netzwerk ist WLAN ac (das Nexus 5x hat aber m.W. kein ac). Der Server ist nicht besonders geschützt. Virenscanner läuft auf dem i7.
Virenscanner ausschalten hilft auch nicht.

Ich habe die Seite gerade mal in Edge geöffnet. Interessanterweise kommen die Items in Edge nach und nach, aber sofort (das letzte braucht aber ähnlich lange; vielleicht etwas weniger lange).

Ich habe bspw. eine Seite auf der alle RTRs, Jalousien etc drauf sind, die braucht auch lange. "normale" Seiten gehen aber sehr schnell.

Ja, so eine Seite ist das hier auch. Aber das darf doch kein Proglem sein 62 Byte zu übertragen :-o

Gruß,
Hendrik

[psilo]

Naja die SV rendert jedes einzelne Item runter, die ganzen HTML Strukturen per JS zu generieren und insbes. die Charts zu bauen (wobei 3 Charts je nach Menge Elemente im Chart nicht soo viel sind) dauert halt.. Wie lange baut denn eine typische (normal befüllte) Seite mit 20-30 Items auf?

[psilo]

Kleine Vergleichsbeispiel anbei.. Laut Laufzeitanalyse ca 6 Sekunden Aufbauzeit. Kannst ja auch mal laufen lassen.. F12 im Firefox um in die Entwicklertools zu kommen

[henfri]

Moin,

ich habe das mal ausprobiert.
Hilft dir das weiter? Mir fehlt der Background.

Eine kleinere Seite habe ich auch beigefügt. Das geht tatsächlich schneller.
Aber es sollte doch auch machbar sein, die 62 Items zügiger zu übertragen, bei der Performance, die die Geräte heute haben.

Gruß,
Hendrik

[psilo]

Ich sehe hier eine "Total Time" von 2 (!!!) Sekunden. Findest Du das wirklich dramatisch?! Ich zweifle an, dass schneller bei der Befüllung via Websockets/JS bei der Menge Items wirklich geht. Bspw. werden Bilder soweit ich das gesehen habe teilweise erst requested, wenn ein Status gesetzt wird. Da kann vielleicht helfen, die SVG Varianten der SV 2.8 zu verwenden, die etwas kleiner als die PNGs sein sollten. Aber ob Du da viel herausholen kannst glaube ich nicht.

[henfri]

Hallo,

die Zeit ist auf dem i7. Auf dem Handy ist es so störend, dass ich es selten nutze.
Und das Gerät ist ja wirklich HighEnd. Beim Hany meiner Frau ist es unbenutzbar. Dass die Bilder erst requested werden, wenn der Status gesetzt wird klingt plausibel. Das Problem ist aber doch die Dauer des Setzen der Statii, welches lange dauert.
Wie gesagt: Das Laden der Seite ist rasend schnell. und es dauert auch lange Items zu holen, die als Zahl und nicht als Icon dargestellt werden.

Gruß,
Hendrik

[psilo]

Naja wenn er bei jeden Status den er via JS setzt evtl noch ein svg/png runterzieht dann dauert das halt im gesamten. Auf meinem galaxy s5 ist es im WLAN fast identisch mit meinem PC (und der hat ne 4790k CPU, 16 gb ram ). Im Mobilnetz ist es aber auch unangehm, wenn nur edge verfügbar ist oder ich gedrosselt wurde. Auf dem iPhone 4 meiner Frau ist es unbenutzbar, das Ding hat aber def. zu wenig CPU Power.

Aktuell werkle ich wieder an meiner nativen Android App, die ich wenn es mal REST gibt mit SmartHomeNG koppeln werde. Die Tage kann ich mal prototypisch von Pull auf Push (Websockets) umbauen. Im Pull ist die App auf jeden Fall massiv schneller als die SV.

Probier vielleicht auch nochmal div. Browser durch. Aktuell nehme ich Chrome her, weil das JS Processing einfach eines der schnellsten ist..

[henfri]

Hallo,

versteh mich nicht falsch, aber das muss schneller gehen. Wenn die Seite an sich lange bräuchte, ok. Aber die Bilder haben wenige KB und sind alle die gleichen. Die Statii sind wenige Byte. Das ist alles nix im Vergleich zu anderen Websites.
Hier mal ein Video vom Huawei P7 aus
https://www.dropbox.com/s/d2ub7zcvof...52-52.mp4?dl=0
Urteile selbst. Den weißen Screen ignorieren wir mal. Der kommt nur beim ersten Mal.
Interessant übrigens, dass es nur beim ersten Öffnen der Seite lange dauert. Die Statii muss er aber beim zweiten mal auch aktualisieren.

Ich nutze ja auch schon Chrome. Bei Edge war angenehmer, dass nicht alles auf einmal kam, sondern die Items nach und nach eintrudelten. Da sieht man wenigstens den Fortschritt.

Erzähl mal mehr von der App. Ich bin neugierig.

Gruß,
Hendrik

[psilo]

hmm ok das huawei video sieht echt strange aus. v.a. die heizungs-seite.. die beiden rechten spalten dauernd DEF zu lange.. evtl dauert schlichtweg der aufbau der websocket verbindung so lange - aber das erklärt nicht den zeitunterschied zw. linker und den beiden rechten spalten... und k.a. wie man das messen könnte.

berechnest du für die % was clientseitig (oder serverseitig im sh.py) oder kommt das direkt vom bus?

[henfri]

Hallo Psilo,

Auf der Heizungs-Seite wundert mich auch, dass einige der Temperatur-Werte früher als andere kommen. Schuppen wundert mich nicht. Den gibt es nicht. Aber Wohnzimmer.. Beim sh.py CLI kommen die Werte sofort (und das auch wenn ich ls eg.Wohnzimmer mache, was ca zwei Seiten voll an Werten ergibt).

(Bleibt die App eigentlich im Hintergrund aktiv und pollt Werte? Gerade eben waren alle Werte sofort da; das Fenster lief allerdings auch noch (im Hintergrund).

Wenn ich es richtig sehe, werden doch die Werte von sh.py in einem Rutsch an die Visu gesendet, oder? D.h. über das sh.py log kommt man nicht weiter:

2016-06-05 21:27:56,519 DEBUG    Main         192.168.177.43:59067 sent '{"cmd":"monitor","items":["eg.Wohnzimmer.ofentaster","eg.Schuppen.heizung.ist","eg.Schuppen.heizung.stellwert","eg.Schuppen.heizung.soll","eg.Flur.heizung.ist" .....  ,"og.Flur.heizung.frostschutz","og.Flur.heizung.heizen"]}' -- __init__.py:json_parse:270

Die % werden auf dem Server gerechnet (Siehe code oben)

Ich habe auch die betreffende Datei angehängt. Aber jede Zeile ruft da das gleiche Macro auf.

Gruß,
Hendrik

[bmx]

Es wäre interessant zu sehen, was tatsächlich an html beim client nachher drin steht. Hast Du mal geschaut, ob Javascript Fehler ausgeworfen werden?

[henfri]

Moin Bernd,

Es wäre interessant zu sehen, was tatsächlich an html beim client nachher drin steht.

Die habe ich angehängt.
Ich sehe da bei 'Wohnzimmer' nix besonderes

Hast Du mal geschaut, ob Javascript Fehler ausgeworfen werden?

Oh ja. Das war ergiebig. Siehe Anhang. Da fehlt ja so einiges. Wie kann das sein? (Ich hole die SV aus dem git: git clone https://github.com/Martin-Gleiss/smartvisu)

Gruß,
Hendrik

[bmx]

Ich glaube Du has das Quad Design vom Niko, oder? Schaue doch mal, ob er die besagten *.JS vielleicht dafür voraussetzt und die bei Dir nur nicht installiert sind...