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....