Ankündigung

**2ndsky** · 17.03.2014, 09:42

Vielleicht solltest du erstmal das Problem beschreiben. Was ist denn langsam?

Bei mir sind Seiten mit vielen Items auch etwas langsamer beim ersten Laden. Allerdings liegt das am Endgerät. Am iPhone und iPad dauerts teilweise drei Sekunden, am Desktop nicht mal eine.

**chrisi** · 17.03.2014, 19:42

Ich habe jetzt nicht wirklich ein Problem damit.
Mir geht es eigentlich nur darum, soviel wie möglich Punkto Performance herauszuholen (auch wenn das jetzt im ms Bereich liegt).

Dafür ist dieser Beitrag/Thread eigentlich dar.
Ich denke mir das wird auch andere User (vorallem alle die einen Raspberry Pi verwenden) interessieren.

**netzkind** · 17.03.2014, 20:09

Zitat von chrisi Beitrag anzeigen

möchte diesen Thread gerne nutzen um Informationen zu sammeln wie man Performance von Smarthome.py/Smartvisu vor allem mit dem RaspberryPi verbessern kann.

Was macht der RasPi denn bei dir? Nur Server oder auch Client/GUI? Da gibt es ja ganz wesentliche Unterschiede...

Zitat von chrisi Beitrag anzeigen

Dazu habe ich im Forum schon einiges gefunden:

1. lighthttpd statt apache verwenden
2. pagechache einschalten (erst wenn Konfiguration komplett fertig ist)
3. Schnelle Speicherkarten verwenden
4. RAM-Disk verwenden. Frage: Welche Teile sollte man in die RAM-Disk auslagern?
5. Bringt übertakten etwas?

Fällt euch sonst noch etwas ein?

- (schneller) USB-Stick statt Speicherkarte - das soll noch mal schneller sein als der Durchsatz der SD-Karte
- Speicheraufteilung anpassen. Wenn es nur ein Server ist, braucht man (fast) keinen Grafik-Speicher und kann mehr Speicher als RAM nutzen
- Services abschalten die man nicht braucht
- Smartvisu basiert auf PHP? Dann APC/Zend OpCache aktivieren

**bytesplit** · 16.04.2014, 08:22

Ähm... dann ergänze ich jetzt mal meine Erfahrungen!

ich habe lighttpd mit xcache am laufen. Das macht erstmal die Verarbeitung von PHP schneller. Dann hab ich noch gzip Caching im lighty aktiviert, was alle js/css/html-Dateien gleich ferig ge-gzip't in /var/cache vorhält. Bei Interesse müsste ich die Config raussuchen.

Das meiste hab ich jetzt am jQuery herumgedoktort...

-- Caching --
in config.php muss 'config_cache_dom' auf false stehen. Sonst wird jede Seite (Etagen, Räume) auf dem Client gespeichert und auf meinem iPhone 4 macht das alles etwas träge, nachdem man alle Seiten besucht hat.

-- Prefetch --
Trotz o.g. Caching will ich meine beliebten Seiten schnell laden (ohne den Loader-Kreisel!). Dazu muss auf der Startseite angegeben werden, welche anderen Seiten im Hintergrund vorgeladen werden sollen. Das geschieht mittels prefetch.

Bei mir mit den quad-Pages in navigation.html suchen nach:

Code:

<a href="index.php?page=licht">

und ergänzen:

Code:

<a href="index.php?page=licht"[COLOR="Red"] data-prefetch[/COLOR]>

D.h. die Seite Licht wird nach dem Aufruf von Smartvisu gleich nachgeladen. Beim Wechsel des Raums machts nur *blink* und da!

Das habe ich für KG, EG, DG und die Übersichten Licht und Rollos gemacht. Da gehen wir am häufigsten hin. Sinn macht es nicht alle Seiten zu prefetchen (denglisch), sondern nur die wesentlichen.

-- XMLHTTPRequest --
Beim Beobachten der Netzwerk-Übertragung fiel mir auf, dass o.g. prefetch ganze Seiten lädt. D.h. jedes mal werden HTML-Kopf, alle Inhalte und -Fuss geladen obwohl nur das div-Element page benötigt wird. Gerade aufm Handy macht das parser-Zeit aus.

Ich habe daher die index.php wie folgt ergänzt:
Zeile 55:

Code:

        // detect AJAX request
        if (isset($_SERVER['HTTP_X_REQUESTED_WITH']) AND strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) === 'xmlhttprequest') {
                $twig->addGlobal('isXMLHTTPrequest', 'true');
        }

Damit haben wir in isXMLHTTPrequest die Frage nach Browser oder Javascript-Nachlade beantwortet. Im Template base.html müssen wir nur noch sicherstellen, dass header und footer nur beim Browser-Besuch geschickt werden. Das geschieht mittels if:

Code:

{% if isXMLHTTPrequest != 'true' %}
<!DOCTYPE html>
...
</head>
<body>
{% endif %}
<div data-role="page" id="{{ page }}" data-theme="a">
...
</div>
{% if isXMLHTTPrequest != 'true' %}
</body>
</html>
{% endif %}

Beobachten wir nun die Netzwerk-Kommunikation, so wird nur beim ersten Aufruf die ganze Seite geladen. Bei allen Folgeanfragen aus jQuery wird nur page ausgeliefert.

-- weitere Ideen --
Ich hab experimentiert und die index.php mit allen Pages in eine statische HTML rausgeschrieben. Das lädt ohne PHP viel schneller und kann auch gzip'ed auf der Platte liegen. Leider ist der DOM dann sehr groß und die Navigation wird viel langsamer (950kB reines HTML). Deshalb jetzt obige Lösung.

Trotzdem möchte ich noch alle css und js-Dateien zusammenfassen um nur je einen HTTP-Request zu haben. Weiterhin wäre es wohl sinnig die png's oder svg's zusammenzubauen. Lösungen wären svg-stacking, sprite-png's oder auch eine icon-Font. Das könnte das Laden der Abbildungen ggf. noch beschleunigen.

Zuletzt bleibt noch die smarthome.py-Anbindung. Es stört mich noch, dass die item-Aktualisierungen 2-3 sek brauchen. Bei Rollos seh ich wie jeder einzeln runterfährt nachdem ich die Seite aufgerufen hab. Eine Idee hab ich aber noch nicht.

Auch stell ich mir noch vor, smartvisu mittels phonegap vielleicht direkt auf's iPad zu bringen um die Ladezeit weiter zu verkürzen. Aber alles zu seiner Zeit.

Jetzt kommt der Frühling und da muss der Garten mal gemacht werden

**henfri** · 16.04.2014, 19:41

Hallo,

danke für deine Erfahrungen.

Zitat von bytesplit Beitrag anzeigen

ich habe lighttpd mit xcache am laufen. Das macht erstmal die Verarbeitung von PHP schneller. Dann hab ich noch gzip Caching im lighty aktiviert, was alle js/css/html-Dateien gleich ferig ge-gzip't in /var/cache vorhält. Bei Interesse müsste ich die Config raussuchen.

Bringt xcache denn auch was, wenn in der SV pagecache=on ist?
Für deine Config wäre ich dankbar. Gzip-Caching klingt ja auf jeden Fall sinnvoll.

-- Caching --
in config.php muss 'config_cache_dom' auf false stehen. Sonst wird jede Seite (Etagen, Räume) auf dem Client gespeichert und auf meinem iPhone 4 macht das alles etwas träge, nachdem man alle Seiten besucht hat.

Hm, wie kommt das?
Ich habe extra deshalb die cache.manifest erzeugt, wobei ich nicht den Eindruck habe, dass das wirklich funktioniert/etwas gebracht hat, denn deine modifkation unten (data-prefetch) bringt richtig was!

[B]-- XMLHTTPRequest --

Das hat bei mir nicht funktioniert. Anbei mal meine Dateien. Würdest du bitte einmal da drüber gucken?

Gruß,
Hendrik

Angehängte Dateien

**bytesplit** · 16.04.2014, 22:23

Zitat von henfri Beitrag anzeigen

Bringt xcache denn auch was, wenn in der SV pagecache=on ist?
Für deine Config wäre ich dankbar. Gzip-Caching klingt ja auf jeden Fall sinnvoll.

Xcache hat halt noch ein paar Variablen im RAM um z.B. zu checken ob es den pagecache rausschicken kann. Die lighty-Konfig such ich morgen mal raus.

Zitat von henfri Beitrag anzeigen

Hm, wie kommt das?
Ich habe extra deshalb die cache.manifest erzeugt, wobei ich nicht den Eindruck habe, dass das wirklich funktioniert/etwas gebracht hat, denn deine modifkation unten (data-prefetch) bringt richtig was!

Dazu musst Du verstehen, was jQuery tut. Bei aktivem Caching wird die Seite nach dem Laden im DOM (Client-Browser) behalten:
Index -> Klick Küche -> Klick Wohnen -> Klick ... Alle diese Page-Elemente werden dem DOM zugefügt. Das geht halt irgendwann auf den RAM, der auf Mobile äh etwas knapp sein kann.

data-prefetch lädt eine gewünschte Seite dagegen vor dem Klick schonmal ins DOM:
Index -> prefetch Küche, Wohnen, ... -> Alles schon da beim Klick
Es macht meiner Meinung nach aber keinen Sinn alles zu prefetchen. Dann steht der Server unter Dauerfeuer - da kommt dann wieder pagecache und evtl. xcache zum Zuge.

cache.manifest hatte ich mir noch garnicht angeschaut. Es kann aber gut sein, dass sich das Konzept mit den jQuery-Templating beißt. Ich würde sagen mit der cache.manifest könnte man die png's, js und css gut speichern. Aber das werd ich mir sicher nochmal verinnerlichen.

Zitat von henfri Beitrag anzeigen

Das hat bei mir nicht funktioniert. Anbei mal meine Dateien. Würdest du bitte einmal da drüber gucken?

Die Position des Loaders in index.php ist relevant! Du kannst twig erst erweitern wenn es initialisiert wurde (bei Dir Zeile 58). Füg den Absatz lieber danach ein. Dann sollte auch das template klappen.

Wenn es funktioniert siehst Du übrigens idealerweise nix

. Dazu musst Du dann schon z.B. den Chrome Network Inspector hernehmen und dir die Antwort anschauen. Der Request sollte xmlhttprequest enthalten und die Antwort nur das page-Element.

Zitat von henfri Beitrag anzeigen

Gruß,
Hendrik

gleichfalls
Philon

**chrisi** · 13.05.2014, 20:08

Ramdisk:
https://knx-user-forum.de/smartvisu/...ches-html.html

**heckmannju** · 14.05.2014, 09:09

Zitat von chrisi Beitrag anzeigen

Hallo,

möchte diesen Thread gerne nutzen um Informationen zu sammeln wie man Performance von Smarthome.py/Smartvisu vor allem mit dem RaspberryPi verbessern kann. Mir ist bewusst das es am einfachsten ist einfach eine stärkere Hardware zu nehmen, aber es ist ja vielleicht auch möglich mit Anpassungen Performanceverbesserungen erziehlen zu können.

Dazu habe ich im Forum schon einiges gefunden:

1. lighthttpd statt apache verwenden
2. pagechache einschalten (erst wenn Konfiguration komplett fertig ist)
3. Schnelle Speicherkarten verwenden
4. RAM-Disk verwenden. Frage: Welche Teile sollte man in die RAM-Disk auslagern?
5. Bringt übertakten etwas?

Fällt euch sonst noch etwas ein?

Einfache Seiten bauen die nicht mit Objekten überladen sind bring meiner Meinung nach am meisten. Da hat man als Benutzer die größte einflussmöglichkeit um ein schnelles UI zu bekommen.

**kdk** · 21.05.2014, 14:14

Hi,

ich habe den Pi übertaktet. Läuft jetzt mit dem selben Takt wie mein Raspbmc.(GPU-Speicher auf 32MB begrenzt)
Es fehlt allerdings die config.txt im /boot Verzeichnis. Muss man halt eine reinkopieren.

Der Seitenaufbau geht seither deutlich schneller.

Allerdings: ich bin Neuling und spiele gerade erst mit den HTML-Seiten in Smartvisu. Noch keine Anbindung an den EIB/KNX. Möchte erst meine Seitengestaltung so hinbekommen wie ich mir das Vorstelle.

Viele Grüße,
Klaus

Ankündigung

Performanceverbesserung mit RasPi

Performanceverbesserung mit RasPi

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar