Ankündigung

**jksd** · 27.01.2022, 17:39

Deine letzte Antwort mit Antworten dazu:

Hi Jörk,
can you come to the forum and send me an PN with a link to your entire SV folder? I would like to test your pages in order to understand more of the root causes for this behaviour. The browser developer tools can give more hints on the time-consuming routines.
What you can do yourself:

edit your menu and remove "data-ajax = false" from the links which causes the page to load from scratch (to be seen after activating your home button) instead of taking it from jQuery mobile page memory via ajax. This should boost performance quite a lot.

Bringt beim initialen Laden nichts. Beim erneuten Laden sieht man so lange einen sehr positiven Effekt, bis ein erneuter Reload ausgeführt wird (der dann wieder sehr lange braucht). Problematisch ist es, dass es sporadische Blockierungen gibt. So leider nicht verwendbar.

if you don't use the roundslider or status.toast widgets, you can remove their jQuery plugins from the import in root.html. Line 50 / 51 is .css import and line 130 / 131 is .js import. These two plugins were the only new external packages brought into smartVISU. It would be interesting to see if there is some impact.

Habe ich entfernt -> Kein Effekt (habe ich auch nicht verwendet)

copy ./vendor/plot.highcharts from v2.9 to v3.2 (after renaming the folder in v3.2). This package has grown a lot over the versions. Maybe you won't be able to use all features of the plot widgets but the functions shown in the docu are working. Also here it would be interesting to see if there is an impact on performance.

Habe ich probiert -> kein nennenswerter Effekt. Ich verwende bisher allerdings auch noch keine Plots (steht noch aus).

Thanks for the support and best regards
Wolfram

Ich habe ein tar ohne Passworte, etc zusammengestellt, dass ich dir gerne privat zur Verfügung stelle. Natürlich fehlt die Datenquelle zu fhem.
Vielen Dank für Deine Unterstützung,
Jörk

**wvhn** · 13.02.2022, 23:18

Mal ein kurzer Zwischenbericht von den Analysen. Wenn jemand sich mit PHP und den Servern Apache2 und Lighttpd gut auskennt, ist er / sie herzlich eingeladen, hier Tipps zu geben.

Die Seite hat insgesamt 263 items und noch mehr Widgetaufrufe. Wir haben Live-Tests an fhem durchgeführt (mit dem JavaScript Websocket Treiber), sowie mit dem Offline-Treiber (JavaScript Treiber, der per Ajax ein PHP-Skript aufruft, das die Daten aus der ./temp/offline_<Seitenname>.var liest). Der Treiber musste erstmal erweitert werden, um so viele Daten anfragen zu können. Weil die Zeichenanzahl für den Request begrenzt ist, muss das Skript 3x mit je bis zu 100 items aufgerufen werden.

Testumgebung 1 (bei @jksd):
Backend: Raspberry 4B mit SSD, hostet smartVISU und fhem. Webserver ist Lighttpd mit PHP v7.3
Panel: XORO Megapad 2404 v2 unter Android 5.1

unter SV 2.9 ist zwischen fhem-Treiber und offline-Treiber praktisch kein Unterschied (19 s Ladezeit), unter SV 3.2 ( 29 - 32 s Ladezeit) ist der offline-Treiber ca. 10% langsamer, als der Websocket Treiber
wegen des schnellen Servers bringt der smartVISU-Cache nichts. Unter SV v3.2 ist die Ladezeit mit Cache (php-basiert) sogar 6% länger
in allen Fällen ist SV 3.2 ca. 50% langsamer als v2.9

Während laut Komplettanleitung das Modul lib-awl für php installiert werden soll, fehlt das hier. Leider ist nirgendwo dokumentiert, wozu dieses in smartVISU gebraucht wird.

Testumgebung 2 (bei mir):
Backend: schneller PC mit SSD (c't Bauvorschlag Allrounder 2020), XAMPP als Apache2-Server mit PHP v7.4
Panel: iPad 2 mit iOS 9.3.5

Das alte iPad ist natürlich deutlich langsamer. Es braucht mit offline-Treiber unter SV2.9 rund 129 s. Unter SV 3.2 ist es um ca. 28 s (20%) schneller (!)
Mit einem reduzierten Satz von 16 Testitems (mehrfach verwendet in den vielen Widgets) an einem shNG-System (Raspberry 1B, shNG v1.9) ist kein Geschwindigkeitsunterschied zwischen den SV-Versionen feststellbar. Die Ladezeit beträgt ca. 52 s. D.h. die Differenz zum vorangegangenen Versuch kommt aus der Menge der zu aktualisierenden items.
im gleichen Test mit shNG ist eine weitere Version SV 3.0 rund 5% langsamer. Für mich ist das ein Zeichen, das die Maßnahmen zur Reduzierung der geladenen JavaScript-Ressourcen in v3.2 Wirkung zeigen.
Wegen des schnellen Servers bringt der smartVISU-Cache nichts. Allerdings bleiben die Ergebnisse mit/ohne Cache gleich.

Die Ergbebnisse sind wohl eine Mixtur aus Laufzeiten des JavaScript-Codes im Endgerät und der php-Kommunikation mit dem Server. Während der JavaScript Code mit zusätzlichen Funktionen von Version zu Version an Volumen zugenommen hat, habe ich nicht benötigte Ressourcen (veralteten Code, config-Seite mit deren Widgets, Templatechecker und Widget Assistent) in v3.2 weitgehend von den Visu-Seiten entfernt. Im Vergleich zu v3.0 war das erfolgreich.
Auf der php-Seite gab es natürlich auch Änderungen, aber evolutionär - keine echten Konzeptänderungen. Wichtig ist sicher das Update von Twig, allerdings müsste sich dies beim Rendern der Seiten bemerkbar machen und weniger zur Laufzeit.

Im Moment scheint es so, dass unter Apache keine großen Unterschiede in der Performance bestehen, während Lighttpd auf die Änderungen in smartVISU empfindlich reagiert. Der Verdacht fällt dabei auf die PHP-Kommunikation. Mithilfe beim Testen und Tipps für die Analysen sind mehr als willkommen!

Gruß
Wolfram

**wvhn** · 14.02.2022, 23:57

Update:
Ich habe in shNG jetzt einfach mal meine items vervierfacht, indem ich die items.yaml 3 mal kopiert habe und im item-Baum jeweils auf Top-Level einen Buchstaben hinzugefügt habe. Dann habe ich eine Seite mit 100 Widgets erstellt.

Mit dem PC als Server gibt es keine Laufzeitunterschiede - tendenziell eher einen kleinen Vorteil für v3.2.1
Kopiere ich die Seiten auf den Raspberry, sieht das ganz anders aus. Hier habe ich eine ältere v2.9 (develop) gefunden, die tatsächlich rund 50% schneller als v3.2.1
Damit kann die Suche losgehen...

**Msinn** · 15.02.2022, 11:44

Wolfram,

Du schreibst, dass Du in Deiner Testumgebung einen Raspberry Pi 1B hast? Ernsthaft?

**wvhn** · 15.02.2022, 19:47

Wohl nicht ganz präzise. "Raspberry Model B+ 512 MB" sagt das Admin Interface. Da läuft ein Buster mit allem drauf, was man braucht. Da ich am PC entwickle, brauche ich den Raspi nur ab und zu, um den Code zusätzlich zu testen. Die Busankopplung kommt über mein Prouktivsystem, auf dem ich nur freigegebene Versionen laufen lasse.

Das Ding ist natürlich langsam, zeigt dadurch aber auch Schwachstellen im Code auf.

**Msinn** · 15.02.2022, 20:48

Ja das Ding ist so langsam, dass wir es für SmartHomeNG nur für absolute Minimalkonfigurationen empfehlen.

Umfangreichere und modernere (Feature reichere) Software tendiert dazu mehr zu rechnen. Das muss per se nicht schlecht sein.
Im Zweifelsfall beweist Du mit dem Pi 1B nur, dass Du mehr rechnen möchtest, als es das „Museumsmodell“ aus dem Jahre 2014 leisten kann.

**wvhn** · 16.02.2022, 19:20

So, einen ersten Erfolg kann ich vermelden.
Wir haben tatsächlich Äpfel mit Birnen verglichen: meine vermeintliche Version v2.9 war eine Zwischenversion aus dem jahrelang bestehenden Develop-Zweig von v2.9. Da sind wir mittlerweile besser aufgestellt, weil wir eine konsequentere Versionierung eingeführt haben. Die Lehre daraus: wirklich genau prüfen, welche Version am Start ist, wenn man solche Vergleichstests macht.

Also habe ich eine richtige v2.9.2 auf meinen Raspberry gespielt und siehe da: die Ladezeiten liegen in der Größenordnung von v3.2.1.

Als nächstes habe ich das Repository in einen neuen Ordner geclont. Was an git echt cool ist: ich kann jeden beliebigen Zwischenstand anhand des Hashs des jeweiligen Commits auschecken und so ohne viel Aufwand Softwarestände testen. So habe ich die Ursache eingekreist, indem ich ausgehend von meiner alten Version v2.9 das Intervall bis zum Release von v2.9.0 immer wieder halbiert habe, bis der Performanceverlust auftrat.

Der verantwortliche Commit ist von einem hier im Forum sehr aktiven Kollegen

Er hat richtigerweise die in jQuery mobile veraltete Methode zum Ansprechen der aktiven Seite

Code:

$.mobile.activePage

durch das neue Pagecontainer-Widget

Code:

$(":mobile-pagecontainer").pagecontainer("getActivePage")

ersetzt. Offenbar forstet der Selektor ":mobile-pagecontainer" das ganze Dokument durch und ist deshalb deutlich langsamer, als die alte Methode. Da dies bei jedem Widget-Update 2 mal aufgerufen wird, summiert sich das bei vielen Widgets massiv.

Zum Test habe ich in der ./lib/base/base.js die meisten Vorkommen der neuen Methode wieder durch die veraltete ersetzt. Damit liegt die Ladezeit der Testseite um 4-5 Sekunden besser und nur leicht hinter der v2.9.2. Angesichts der deutlichen Funktionserweiterungen von v2.9.2 auf v3.2.1 ist das meiner Meinung nach akzeptabel.

Für Ungeduldige stelle ich die improvisierte base.js passend zur v3.2.1 in einem Gist zur Verfügung und mache mich dann demnächst mal an eine dauerhafte Lösung.

Gruß
Wolfram

Ankündigung

SmartVISU V3.x Performance

SmartVISU V3.x Performance

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar