FHEMWEB XHR=1 und gzip

[Matthias]

Hi,

AndFHEM verwendet die xmllist von FHEMWEB als Austauschformat für die Anwendung. Die Schnittstelle ist schlicht unheimlich komfortabel zu benutzen.

Der Nachteil an der Geschichte ist nur, dass man unheimlich große Datenmengen anschließend transportieren muss. Ich weiß von Leuten mit Plain-Text xmllist Dateien von 3MB oder mehr. Ich frage mich also ob es möglich wäre einen zusätzlichen Parameter einzuführen, der bei XHR=1 die Antwort in gzip o.ä. zurückgibt. Das dürfte die Antwort mindesten um einen Faktor 10 verkleinern und gerade Leuten mit großen FHEM Instanzen helfen.

Wenn es einen besseren Platz für diese Frage gibt bitte den Thread verschieben

Vielen Dank,
Matthias

[Real-TTX]

Die Antwort wird, wie in fast allen Fällen bereits gzip komprimiert zurückgegeben. Ist Sache des Clients / Servers...

Siehe:

Code Auswählen Erweitern

Request URL:http://10.10.1.18:8083/fhem?cmd=xmllist&XHR=1
Request Method:GET
Status Code:200 OK
Remote Address:10.10.1.18:8083

Content-Encoding:gzip
Content-Length:75256
Content-Type:text/plain; charset=UTF-8

Viele Grüße,

Real-TTX (Matthias  )

[Matthias]

Hi,

cool, das probiere ich gleich aus. Vielen Dank!

Matthias

[Real-TTX]

Warst zu schnell:

Nachtrag 1.)

Das Problem ist eher, dass soviel "Schrott" mit übertragen wird. In meiner App (Home+) kämpfe ich mit einem ähnlichen Problem...

Du könntest als erstes auf jsonlist2 umstellen. Würde dir schon eine Menge an Overhead sparen... Der Aufwand sollte nicht wirklich groß sein...


Nachtrag 2.)

Ausprobieren? Das bekommst du eigentlich gar nicht mit. Du kannst es nicht beeinflussen. Die Daten werden bereits jetzt komprimiert gesendet und von deiner Bibliothek entpackt. Ich denke du verwendest aktuell den "DefaultHttpClient" ?

Viele Grüße

[Matthias]

Hi,

naja du musst zumindest noch das "accept-encoding" als Request Header einstellen.

Nein, man soll ja mittlerweile die HttpUrlConnection verwenden. Gerade scheint es zumindest nicht so als ob das automatisch passieren würde. Ich vergleiche aber gerade die Zeiten.

Matthias

[Real-TTX]

Hast vollkommen Recht.... In meinem Leichtsinn, bin ich von meinen verwendeten Libs ausgegangen - hier ist es bereits unter den DefaultHeaders hinterlegt....

Viel Erfolg!

[Matthias]

Kommando zurück - du hast Recht.

Erstmal:
Wenn man den Header setzt kommt man auf ähnliche Zeiten. Bei meiner xmllist zuhause sind es gerade 4800ms, wobei die Zeit zwischen 4500 und 5000ms variiert. Mit explizitem gzip sind die Zeiten mehr oder weniger identisch.

Nach ein bisschen Suchen bin ich auf die Doku zu HttpUrlConnection gestoßen:
By default, this implementation of HttpURLConnection requests that servers use gzip compression and it automatically decompresses the data for callers of getInputStream(). The Content-Encoding and Content-Length response headers are cleared in this case. (https://developer.android.com/reference/java/net/HttpURLConnection.html)

Mit anderen Worten - der Flaschenhals ist nicht die Übertragung, sondern die Generierung der xmllist

Viele Grüße,
Matthias

[rudolfkoenig]

5 Sekunden fuer xmllist sind schon recht lang.
Wieviele Geraete hast du den, und auf welchem Hardware laeuft FHEM?

Ich brauche auf meinem alten Notebook bei einem FHEM-Config mit 1720 Definitionen 0.58s fuer Erzeugen und mit wget Abholen der xmllist und 0.6s fuer jsonlist2. Das XML ist mit 4996679 nur unwesentlich groesser als das JSON mit 4848691 Bytes, beides unkomprimiert.

Ich tippe auf das Parsen des XMLs, das war frueher unter Android langsam (DOM) oder muehsam (SAX).
Hat sich da was geaendert?

[Matthias]

Hi Rudolf,

meine Geräteliste enthält gerade 300 Geräte:

Code Auswählen Erweitern


$ grep name=\" xmllist | wc -l
300


Unkomprimiert sind das gerade ~800kB:

Code Auswählen Erweitern


$ ls -al xmllist
-rw-r--r-- 1 klassm klassm 810957 Jan 28 14:05 xmllist


Ich habe aber wohl noch eine relativ kleine Instanz . Der Grund für die lange Laufzeit ist wahrscheinlich tatsächlich die Hardware. Der Raspberry Pi (2nd gen) ist jetzt nicht unbedingt schnell . Das Zerlegen des xmls war tatsächlich in der Zeit nicht enthalten. Das ist die reine Generierung- und Übertragungszeit zum Handy.

Matthias

[rudolfkoenig]

Hast du deine Zeit mit wget/curl oder in Android gemessen? Mein 7 Jahre alter Rechner waere nach den Zahlen (4.8/0.58)*(4996679/810957) = 51 mal schneller als ein RPi2. 5 bis 10-mal faende ich realistischer.

[Matthias]

Die Zeiten sind auf Android gemessen, genau zu dem Zeitpunkt, wenn der "String" wieder zusammengebaut ist. Mit wget ändern sich die Zeiten aber auch nicht wirklich. Die CPU Last geht für die Zeit auf dem Raspbi aber auch tatsächlich auf 100%. Ich denke schuldig ist wirklich die Hardware

Code Auswählen Erweitern


$ time wget --user=bla --password='blub' --no-check-certificate 'https://bla.blub.li:8084/fhem?cmd=xmllist&XHR=1'                                                                           
2017-01-28 14:21:19--  https://bla.blub.li:8084/fhem?cmd=xmllist&XHR=1
Auflösen des Hostnamens »bla (bla)« ... 79.xxx.71.xxx
Verbindungsaufbau zu bla (bla)|79.xxx.71.xxx|:8084 ... verbunden.
WARNUNG: Das Zertifikat von »bla« kann nicht geprüft werden, ausgestellt von »»xxx««:.
  Ein selbst-signiertes Zertifikat wurde gefunden.
    WARNUNG: Der Common Name »»xxx«« des Zertifikates entspricht nicht dem angeforderten Hostnamen »»xxx««.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 401 Authorization Required
Authentifizierung ausgewählt: Basic realm="FHEM: login required"
Wiederverwendung der bestehenden Verbindung zu bla:8084.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ... 200 OK
Länge: 809213 (790K) [text/plain]
Wird in »»fhem?cmd=xmllist&XHR=1«« gespeichert.

fhem?cmd=xmllist&XHR=1                               100%[=====================================================================================================================>] 790,25K  1,28MB/s    in 0,6s   

2017-01-28 14:21:24 (1,28 MB/s) - »fhem?cmd=xmllist&XHR=1« gespeichert [809213/809213]

wget --user=bla --password='blub!' --no-check-certificate   0,01s user 0,03s system 0% cpu 5,283 total


[androsch]

Hallo,

ich darf mich hier mal einschalten, denn ich bin der Verursacher der langsamen xmllist von Mathias.

Ich habe meinen FHEM-Sever auf einem Pine64 laufen, das Generieren der xmllist dauert bei mir ca. 5-7min, bis FHEM wieder ansprechbar wird, d.h. die FHEM-Instanz braucht quasi eeeewig, bis sie die Liste überhaupt erzeugt. Was kann denn eine solch langsame xmllist verursachen? Habe configDB und ca.

config: 13698 entries

Ver 0 saved: Sat Jan 28 10:32:52 2017 def: 395 attr: 1887
Ver 1 saved: Sat Jan 28 10:30:58 2017 def: 395 attr: 1887
Ver 2 saved: Sat Jan 28 10:29:02 2017 def: 395 attr: 1887
Ver 3 saved: Sat Jan 28 10:27:52 2017 def: 395 attr: 1887
Ver 4 saved: Sat Jan 28 10:12:02 2017 def: 395 attr: 1887
Ver 5 saved: Sat Jan 28 08:52:40 2017 def: 395 attr: 1887
-----------------------------------------------------------------
state: 3520 entries saved: Sat Jan 28 18:27:04 2017
-----------------------------------------------------------------
filesave: 37 files stored in database

also auch keine allzuu große Instanz. Ein Erhöhen und Cachen in mysql hat auch keine Geschwindigkeitsvorteile gebracht. Liest die xmllist überhaupt aus der Datenbank in Verbindung mit configDB oder ist das ein FHEM-internen Prozess?

Sorry, falls ich hier eher komische Informationen gebe, ich bin nur DAU und versuche zu verstehen, was ihr Profis mit FHEM so alles anstellt

EDIT: Habe mal ein wenig mit xmllist herumgespielt, die Hauptzeit verbrät FHEM beim Erzeugen der HTTPMOD Geräte (Fernsehprogramm etc.), ein xmllist TYPE!=HTTPMOD geht immer noch langsam (20-30 sec.) aber Klassen schneller als mit...

[rudolfkoenig]

xmllist (und jsonlist) fragt jedes Geraet einzeln nach den verfuegbaren Befehlen mit "set XXX ?". Ich vermute, dass manche Module dabei nicht optimal vorgehen. Die mysql Konfiguration sollte dabei egal sein. 

Da man auch mit "attr global verbose 5" nicht mehr sieht: kannst du bitte in FHEM/98_XmlList.pm in der Zeile 58 (vor IsIgnored) folgendes einfuegen:

Code Auswählen Erweitern

Log 1, "Dump $d / $defs{$d}{TYPE}";
und

Code Auswählen Erweitern

reload 98_XmlList
attr global mseclog
xmllist
(eins nach dem anderen) in FHEM ausfuehren, und das entstandene FHEM-Log hier anhaengen?

[androsch]

Hallo Rudi,

ist mir ein Ehre:

[snip]zu langes Logfile gelöscht sorry

[androsch]

Nochmal ich:

Mir kam es etwas komisch vor, daß das Logfile die xmllist ja mehrmals aufführt, deshalb nochmal nachgestellt. Logfile gelöscht und nur 1x xmllist eingegeben, dann wird folgendes Logfile erzeugt:

[snip]langes Logfile gelöscht

Logfile hängt am nächsten Post.

Hatte noch angemerkt:

Anscheinend wird die xmllist 5x nacheinander erzeugt, das dauert natürlich.

Ausserdem ist der FHEM-Server an sich ohne nennenswerte Auslastung und auch von einem anderen Gerät aus ganz normal ansprechbar. Nur das Webinterface mit der xmllist hängt ein paar Minuten lang und reagiert nicht. Deshalb die Idee, daß ev. durch die 5 Versionen, die ich in der configDB vorhalte das xmllist 5x erzeugt werden muss und deshalb so lange dauert...

Aber nur eine DAU-Annahme....

[rudolfkoenig]

Apropos Ehre: Du hast die Ehre die Logs als Anhang hinzuzufuegen, und den Rest (in beiden Beitraegen) zu entfernen: Einzelne Beitraege koennen leider nicht beliebig lang werden, und damit ist dein Log abgeschnitten und unbrauchbar.

Kannst du bitte auch die Definition von UnwetterKarteBayern zeigen (samt Attribute)?

[androsch]

Hallo Rudi,

ok, sorry, habe ich nicht bedacht. Werde ich gleich ändern.

Meinerseits noch die Anmerkung: Ich habe im configDB 5 Versionen rückwirkend in der Datenbank, kann es sein, daß er die alle 5 Versionen nacheinander abarbeitet und deshalb so lange braucht?

Letztes Log hängt hier schon mal als Anhang dran....

Hier auch die Unwetterkarte:

Internals:
   CFGFN
   DEF        htmlCode {UWZAsHtmlKarteLand("Unwetterzentrale","Bayern")}
   LINK       {UWZAsHtmlKarteLand("Unwetterzentrale","Bayern")}
   NAME       UnwetterKarteBayern
   NR         228
   STATE      initialized
   TYPE       weblink
   WLTYPE     htmlCode
Attributes:
   room       Wetter

[rudolfkoenig]

configDB ist irrelevant: Die Definitionen/Attribtue/etc werden aus dem Hauptspeicher und nicht aus Datei/DB/etc gelesen.

Kannst du bitte noch:

Code Auswählen Erweitern

Log 1, "DONE:".length($str);
in FHEM/98_XmlList.pm/Zeile 105 (vor dem return) einfuegen und alles wiederholen?

"UnwetterKarteBayern" verursacht bei mir keine Probleme, ich vermute, sie ist einfach nur die Letzte in der Liste.

[androsch]

Hallo Rudi,

hatte zwischenzeitlich ein configdb reorg 0 gemacht. Das Logfile1 zeigt danach nur einen Durchlauf an, auch wenn das Webinterface immer noch mehrere Minuten hing.

Logfile2 zeigt das Ergebnis mit dem neuen Code, Dauer waren ca. 8 min, sieht man ja auch am Datum, in der Zeit ist mein Firefox komplett tot.

Hoffe, das hilft...

[rudolfkoenig]

XmlList ist jedenfalls unschuldig, es sind etliche Aufrufe mit unterschiedlichen Parameter:

- XmlList: 0.734s, 3.2MB
- 13.19s Pause
- XmlList: 0.714s, 3.2MB
- 0.25s Pause
- XmlList: 0.707s, 3.2MB
- 130s Pause
- XmlList: 0.107s, 200k, wohl eine Untermenge angefordert
- 40s Pause,
- XmlList: 0.046s, 1k
- 93s Pause,
- XmlList: 0.046s 1k
- 56s Pause,
- XmlList: 0.725s, 3.2MB
...
usw.

[androsch]

Mit dem aktuellen Update von andFHEM und FHEM läuft es auf jeden Fall wieder, auch wenn die xmllist im Browser immer noch entsprechend lange für Stillstand sorgt...

Danke für den schnellen Support.