Website über ESP8266 generieren - möglichst resourcenschonend

[hacker-tobi (Gast)]

Hi,

einige haben vielleicht mitbekommen, das ich an einem kleinen Webserver 
für IoT-Geräte auf Basis des ESP8266 arbeite.

Das Projekt habe ich auch hier im Forum verlinkt:

Beitrag "TOISWITCH - IoT I/O-Server für ESP8266"

Die aktuellste Version liegt hier:

https://sourceforge.net/projects/toiswitch/

Ich habe mich gefragt, ob ich die Generierung der Website nicht 
effizienter gestalten kann. Bis jetzt verwende ich für das Erstellen des 
HTML Quelltext eine Reihe von strcat() - Aufrufen, Bsp:

                       strcat(user_str,"<input type=\"radio\" id=\"portstate_");
                        strcat(user_str,temp);
                        strcat(user_str,"\" name=\"new_state_");
                        strcat(user_str,temp);
                        strcat(user_str, "\" value=\"on\" onchange=\"this.form.submit()\"><label for=\"portstate_");
                        strcat(user_str,temp);
                        strcat(user_str, "\">ON</label><input type=\"radio\" id=\"portstate_");
                        strcat(user_str,temp);

Problem ist, das ein großer Teil der Inhalte dynamisch erzeugt wird, wie 
auch im Auszug zu sehen ist. Die Variable temp z.B. enthält in diesem 
Fall eine dynamisch erzeugte ID, welche für die Auswertung des Formulars 
benötigt wird.
Aber auch viele andere Parts sind dynamisch erstellt, und enthalten z.B. 
Port-Stati, Listen von Konfigurierten Profilen und Schaltzeiten oder 
andere dynamische Daten.
Daher kann ich die Page oder auch große Teile davon nicht einfach im 
Flash speichern und dann von dort abrufen.
Ich frage mich daher, ob es eine Möglichkeit in C gibt, die 
strcat-Aufrufe effizienter zu gestalten.

Das ganze ist reine Optimierung, die Aufrufzeiten liegen unter 2 
Sekunden, ist also nur nice2have.
Also bei Ideen - gerne her damit.

gruß und danke

tobi

[Stefan F. (Gast)]

Eine gängige Alternative wäre, die Webseiten zusammenhängend als Datei 
(oder String-Konstanten) abzulegen. Der Code kann dann Platzhalter darin 
mit Werten auffüllen wie:

[pre]
Hallo {username}, es ist jetzt {uhrzeit} Uhr.
[pre]

Auch Wiederholungen für Listen und Tabellen sind damit machbar, siehe 
http://stefanfrings.de/qtwebapp/api/classstefanfrings_1_1Template.html#details

Allerdings braucht man dafür immer noch viel RAM. Das Konzept passt 
daher nicht so gut auf den ESP8266.

Mir ist nicht klar, warum du überhaupt String-Fragmente aneinander 
hängst.

Die HTTP Kommunikation basiert auf TCP/IP, das Protokoll ist Datenströme 
gedacht. Da müsste es doch sinnvoller sein, die Häppchen einfach 
nacheinander auszugeben, so wie man das auch mit printf() bei 
Bildschirmausgaben machen würde.

[N. M. (mani)]

Alles dynamische über asynchrone Requests abholen? Stichwort AJAX.

[Εrnst B. (ernst)]

Stefan ⛄ F. schrieb:
> Allerdings braucht man dafür immer noch viel RAM. Das Konzept passt
> daher nicht so gut auf den ESP8266.

z.B.

https://github.com/me-no-dev/ESPAsyncWebServer#template-processing

Verwendet dafür chunked replies, d.H. die komplette Webseite muss 
garnicht in den RAM passen.

[hacker-tobi (Gast)]

Hi,

danke erstmal für die antworten.

ich hab kein RAM Thema, die Website ist max. etwa 6 kB gross.
Ich frage mich nur ob ich die Ausgabe noch weiter optimieren kann 
hinsichtlich Geschwindigkeit.

Ich denke, chunked requests gehen da für mich nicht in die richtige 
Richtung, sind aber eine gute Idee, wenn die site noch größer werden 
sollte. Danke dafür.

Die Idee mit den templates finde ich ganz interessant, aber bringt das 
bei der Verarbeitungsgeschwindigkeit wirklich Vorteile? hier muss ja die 
site mehrfach durchsucht werden, um die variablen zu ersetzen.
Das werd ich mir anschauen.

Gibt es in C evtl eine Funktion, die das zusammen setzen von strings 
gegenüber strcat noch schneller beherrscht?

[Stefan F. (Gast)]

hacker-tobi schrieb:
> Die Idee mit den templates finde ich ganz interessant, aber bringt das
> bei der Verarbeitungsgeschwindigkeit wirklich Vorteile?

Nö. Es macht den HTML Quelltext besser lesbar, das ist aber auch alles.

> hier muss ja die site mehrfach durchsucht werden,
> um die variablen zu ersetzen.

Korrekt. Einen Wettbewerb für Effizienz gewinnst du damit auf keinen 
Fall. Andererseits ist die Geschwindigkeit der Ein-/Ausgabe in der Regel 
eher das Nadelöhr.

[hacker-tobi (Gast)]

Kurz noch zum Thema RAM:

Ich habe aktuell noch ca 28 KB RAM (heap) frei, wenn ich parallel mqtt 
über SSL nutze und die maximale Anzahl von Profilen und timer events 
genutzt wird (also worst-case) .

Der RAM für die Erstellung der Website wird dynamisch allokiert und nach 
Aussenden wieder frei gegeben, aktuell sind das max. etwa 6kB.

Für die Bearbeitung von get/post Requests werden dann noch einige lokale 
Variablen, welche ca 2kB belegen, genutzt.
Diese werden nach der Bearbeitung der Requests mit Verlassen der 
Funktionen wieder freigegeben. Zudem ist zum Zeitpunkt der Bearbeitung 
der requests der Platz auf dem Heap, welcher für das
erstellen der Website benötigt wurde, schon wieder freigegeben.

Ergo hab ich selbst unter schlechtesten Bedingungen immer noch ca 22 kB 
RAM frei, während die Website erstellt wird.

[Stefan F. (Gast)]

Da RAM offenbar kein Problem ist, würde ich nicht extra Zeit in die 
Optimierung der oben gezeigten Code Zeilen stecken - außer im Sinne der 
Lesbarkeit.

Warum willst du überhaupt optimieren, läuft da etwas zu langsam? Falls 
ja, liegt die Problemursache bestimmt nicht an den oben gezeigten 
Zeilen.

[Εrnst B. (ernst)]

Stefan ⛄ F. schrieb:
> hacker-tobi schrieb:
>> Die Idee mit den templates finde ich ganz interessant, aber bringt das
>> bei der Verarbeitungsgeschwindigkeit wirklich Vorteile?
>
> Nö. Es macht den HTML Quelltext besser lesbar, das ist aber auch alles.

Naja, wenn man's ganz theoretisch angehen will, das eine ist O(n), das 
andere O(n²).
In der Praxis, bei so kleinen Webseiten, macht das aber keinen großen 
Performance-Unterschied.

Bei der Kommunikation ESP<>Browser lässt sich vmtl. viel mehr rausholen.
z.B. unötiges Seiten-Reload vermeiden, entweder "hipp", wie von mani 
vorgeschlagen, per 
Single-Page-App/Websocket/DHTML/Ajax/$AkutellesBuzzword™, oder z.B. 
oldschool mit Antwort "204 No Content" auf POST.

[hacker-tobi (Gast)]

Hi,

den Tip mit dem 204 finde ich sehr interessant. Ein wirkliches Problem 
gibt es nicht, die iot devices reagieren wie schon geschrieben recht fix 
das ist eher mein optimierungs fimmel ;)

Danke euch erstmal.

Ich hoffe ich vergesse nicht zu schreiben wenn ich Ergebnisse Ergebnisse 
habe