Autor Thema: FHEMWEB XHR=1 und gzip  (Gelesen 700 mal)

Offline Matthias

  • Full Member
  • ***
  • Beiträge: 280
FHEMWEB XHR=1 und gzip
« am: 28 Januar 2017, 13:06:11 »
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

Offline Real-TTX

  • Full Member
  • ***
  • Beiträge: 141
Antw:FHEMWEB XHR=1 und gzip
« Antwort #1 am: 28 Januar 2017, 13:12:42 »
Die Antwort wird, wie in fast allen Fällen bereits gzip komprimiert zurückgegeben. Ist Sache des Clients / Servers...

Siehe:

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  :P :P)
Server: 3x Supermicro A1SAi-2750F, FHEM @ Debian-VM
Bandwidth: 800 Mbit / 100 Mbit, Failover LTE
Homematic: 2x HM-MOD-RPI-PCB (via Pi3 socat)
Z-Wave: Z-Wave.Me USB Stick (via Pi3 socat)
RFXTrx: RFXCom (via Pi3 socat)

Offline Matthias

  • Full Member
  • ***
  • Beiträge: 280
Antw:FHEMWEB XHR=1 und gzip
« Antwort #2 am: 28 Januar 2017, 13:14:50 »
Hi,

cool, das probiere ich gleich aus. Vielen Dank!

Matthias

Offline Real-TTX

  • Full Member
  • ***
  • Beiträge: 141
Antw:FHEMWEB XHR=1 und gzip
« Antwort #3 am: 28 Januar 2017, 13:18:17 »
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

Server: 3x Supermicro A1SAi-2750F, FHEM @ Debian-VM
Bandwidth: 800 Mbit / 100 Mbit, Failover LTE
Homematic: 2x HM-MOD-RPI-PCB (via Pi3 socat)
Z-Wave: Z-Wave.Me USB Stick (via Pi3 socat)
RFXTrx: RFXCom (via Pi3 socat)

Offline Matthias

  • Full Member
  • ***
  • Beiträge: 280
Antw:FHEMWEB XHR=1 und gzip
« Antwort #4 am: 28 Januar 2017, 13:22:12 »
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

Offline Real-TTX

  • Full Member
  • ***
  • Beiträge: 141
Antw:FHEMWEB XHR=1 und gzip
« Antwort #5 am: 28 Januar 2017, 13:24:50 »
Hast vollkommen Recht.... In meinem Leichtsinn, bin ich von meinen verwendeten Libs ausgegangen - hier ist es bereits unter den DefaultHeaders hinterlegt....

Viel Erfolg!

Server: 3x Supermicro A1SAi-2750F, FHEM @ Debian-VM
Bandwidth: 800 Mbit / 100 Mbit, Failover LTE
Homematic: 2x HM-MOD-RPI-PCB (via Pi3 socat)
Z-Wave: Z-Wave.Me USB Stick (via Pi3 socat)
RFXTrx: RFXCom (via Pi3 socat)

Offline Matthias

  • Full Member
  • ***
  • Beiträge: 280
Antw:FHEMWEB XHR=1 und gzip
« Antwort #6 am: 28 Januar 2017, 13:27:26 »
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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 16721
Antw:FHEMWEB XHR=1 und gzip
« Antwort #7 am: 28 Januar 2017, 14:03:44 »
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?

Offline Matthias

  • Full Member
  • ***
  • Beiträge: 280
Antw:FHEMWEB XHR=1 und gzip
« Antwort #8 am: 28 Januar 2017, 14:08:14 »
Hi Rudolf,

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

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

Unkomprimiert sind das gerade ~800kB:
$ 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
« Letzte Änderung: 28 Januar 2017, 14:15:31 von Matthias »

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 16721
Antw:FHEMWEB XHR=1 und gzip
« Antwort #9 am: 28 Januar 2017, 14:15:22 »
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.

Offline Matthias

  • Full Member
  • ***
  • Beiträge: 280
Antw:FHEMWEB XHR=1 und gzip
« Antwort #10 am: 28 Januar 2017, 14:24:54 »
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 :-)

$ 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

Offline androsch

  • New Member
  • *
  • Beiträge: 46
Antw:FHEMWEB XHR=1 und gzip
« Antwort #11 am: 28 Januar 2017, 18:37:28 »
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...
« Letzte Änderung: 28 Januar 2017, 18:50:50 von androsch »

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 16721
Antw:FHEMWEB XHR=1 und gzip
« Antwort #12 am: 28 Januar 2017, 19:14:06 »
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:
Log 1, "Dump $d / $defs{$d}{TYPE}";und
reload 98_XmlList
attr global mseclog
xmllist
(eins nach dem anderen) in FHEM ausfuehren, und das entstandene FHEM-Log hier anhaengen?

Offline androsch

  • New Member
  • *
  • Beiträge: 46
Antw:FHEMWEB XHR=1 und gzip
« Antwort #13 am: 28 Januar 2017, 20:16:49 »
Hallo Rudi,

ist mir ein Ehre:

[snip]zu langes Logfile gelöscht sorry
« Letzte Änderung: 28 Januar 2017, 20:48:34 von androsch »

Offline androsch

  • New Member
  • *
  • Beiträge: 46
Antw:FHEMWEB XHR=1 und gzip
« Antwort #14 am: 28 Januar 2017, 20:36:14 »
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....
« Letzte Änderung: 28 Januar 2017, 20:51:52 von androsch »

 

decade-submarginal