HttpUtils aktiviert ab sofort die Komprimierung

[rudolfkoenig]

@Wernieman: danke fuer den Hinweis, ich habe deflate.conf folgendermassen erweitert:

Code Auswählen Erweitern

<IfModule mod_deflate.c>
...
        <FilesMatch "\.(pm|css|svg)$">
                SetOutputFilter DEFLATE
         </FilesMatch>
</IfModule>

und damit werden die anderen Dateien auch komprimiert.

[Ein User]

Hallo,

wir haben uns heute an fhem gewendet, um den Traffic auf k***k.de etwas einzugrenzen. Hintergrund ist, dass die Daten unkomprimiert und im 30s Rythmus abgerufen werden. Das führt zu erheblichen Traffic, der eigentlich garnicht nötig wäre.

Daher war unsere Bitte, die Komprimierung einzuschalten und so den Aufwand zu reduzieren.

Als Beispiel sei hier der Traffic aus folgendem Link angeführt:

https://wiki.fhem.de/wiki/Diskussion:HTTPMOD

Die URL http://www.k***k.de/fernsehprogramm/was-laeuft-gerade/0/-1/free.html verursacht derzeit 360Kb Traffic und komprimiert 37kb.

Wir haben heute serverseitig die Komprimierung bei den Anfragen erzwungen, was wohl aber zu Problemen bei den Abfragen führt. Wir hoffen das diese sich durch Updates leicht beheben lassen.

Danke & Viele Grüße

Ein User

[helmut]

Hintergrund ist, dass die Daten unkomprimiert und im 30s Rythmus abgerufen werden.

Bei mir ist das Intervall auf 7200 Sekunden eingestellt - falls sich im Laufe des Tages etwas aendert.
Was waere denn aus Sicht eines Insiders ein sinnvoller Wert?

Gruss Helmut

[Wernieman]

@rudolf
Gern geschehen. Wenn Du in der Richtung noch mehr Probleme hast, einfach Fragen. Dann brauche ich nicht noch weiter zu analysieren? Hätte sonst morgen etwas Zeit ...

[rudolfkoenig]

@Wernieman: im Moment gibt es keine Probleme, evtl. werden demnaechst welche gemeldet, wenn beim FHEM-update die Dateien komprimiert bestellt werden

@Ein User: Die erzwungene Komprimierung sehe ich nicht:

Code Auswählen Erweitern

fhem> { HttpUtils_NonblockingGet({ url=>"http://www.klack.de/fernsehprogramm/was-laeuft-gerade/0/-1/free.html",callback=>sub($$$){ Log 1,"ERR:$_[1] DATA:".length($_[2])." ".substr($_[2], 0, 100) } }) }
liefert mit attr global verbose 5 und attr global httpcompress 0

Code Auswählen Erweitern


HTTP/1.1 200 OK
Date: Thu, 07 Dec 2017 18:30:12 GMT
Server: Apache
Set-Cookie: d2eb32ef92ab9e953aa00bd5b54b2c06=23a303bab2ff4044fda554e821ee4d81; path=/
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Cache-Control: no-cache
Pragma: no-cache
Vary: Accept-Encoding
Connection: close
Content-Type: text/html; charset=utf-8
2017.12.07 19:30:10.650 1: ERR: DATA:374030 <?xml version="1.0" encoding="utf-8"?>...

Allerdings ist das meiner Ansicht nach auch richtig so, und damit kompatibel mit der alten HttpUtils Version, d.h. die FHEM-Benutzer sollten nichts merken.


Falls man "attr global httpcompress 0" nicht setzt (so verhaelt sich HttpUtils.pm ab dem morgigen FHEM-update), dann kommen die Daten wie bestellt komprimiert:

Code Auswählen Erweitern

HTTP/1.1 200 OK
Date: Thu, 07 Dec 2017 18:29:52 GMT
Server: Apache
Set-Cookie: d2eb32ef92ab9e953aa00bd5b54b2c06=150b4aa3d19b0e53d26504fd1361397f; path=/
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Cache-Control: no-cache
Pragma: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 37147
Connection: close
Content-Type: text/html; charset=utf-8
2017.12.07 19:29:53.753 1: ERR: DATA:376111 <?xml version="1.0" encoding="utf-8"?>...


Die Datenmenge reduziert sich tatsaechlich etwa um Faktor 10. Fernsehen halt

[Ein User]

@rudolfkoenig:
Die Komprimierung ist nun an, ich vermute mal, das führt beim "alten" Client zu Problemen.

Wie läuft denn grundsätzlich so ein FHEM Update? Wenn ich es richtig verstanden habe, müssen die Anwender die Kompression doch weiterhin manuell aktivieren, oder?

[rudolfkoenig]

Wie läuft denn grundsätzlich so ein FHEM Update?

Der Benutzer muss in FHEM update eintippen. Es gibt auch verrueckte selbstlose Benutzer, die fuer die Wohle der Allgemeinheit update automatisch taeglich ausfuehren, und damit als Tester Fehler zeitnah melden. Die in die Versionverwaltung eingecheckte Dateien werden fuer diesen Mechanismus jeden Tag kurz vor 8:00 zur Verfuegung gestellt. D.h. ein update morgen ab 8 und ein FHEM-Neustart bewirkt, dass HTTPMOD die Daten von jedem Webserver mit Komprimierung bestellt, und falls sie komprimiert geliefert werden, dann auch entpackt.

Die Benutzer muessen ausser update; shutdown restart nichts machen, komprimiert bestellen ist die Voreinstellung.

[supernova1963]

An alle, denen ich Unannehmlichkeiten bereitet habe,

es lag und liegt nicht in meiner Absicht unnötig traffic zu verursachen und schon gar nicht "Probleme und vielleicht auch Ärger mit dem Provider" zu verursachen.

Mein größter Fehler war einer Empfehlung folgend den Titel des Themas zu ändern und die Bitte zur Unterstützung im Thema "Aktuelles TV-Programm in FHEM" zu platzieren.

Ja, ich habe 4 HTTPMOD devices automatisiert anlegen lassen. 2 davon mit einer vorgegebenen Aktualisierung von 1 Minute, 2 im letzen Update mit 1 Stunde. Die einzelnen TVSender haben nur die Readings der HTTPMOD Devices abgefragt. Dass Terrabyte an Traffic dadurch entstehen kann, habe ich nicht für möglich gehalten und verstehe ich auch jetzt noch nicht so ganz (Ist nach meinem Verständnis eine Frage der Anzahl der Nutzer und des Zeitraumes wie diese Summe aus ca. 400 kb entstehen können). Selbst bei aktivierter Komprimierung würde sich der traffic ja nur um den Faktor 10 reduzieren.
Aus diesen Gründen habe ich heute alles gelöscht und alle Nutzer im Foren Thema gebeten das Modul ebenfalls zu löschen um weitere Unannehmlichkeiten zu vermeiden.

Ich hoffe, "man" kann mir verzeihen.

P.S.: Jede anzeigte Sendung enthielt auch immer einen Link zur Seite von kl**k.de.

[Ein User]

@supernova1963:
Es geht hier garnicht um Vorwürfe, sondern nur darum, die momentane Situation etwas zu entschärfen. Ich denke durch die aktivierte Kompression und die Reduktion der Anfragen pro Tag wären die akuten Themen schon entschärft.

Viele Grüße

Ein User

[CoolTux]

Auch der Umbau des Moduls hat eine Menge Traffic genommen, da nur noch 2 Anfragen alle vielleicht 30 min gekommen wären. Ausserdem hätte man im Modul das Ändern des Abrufintervalls kleiner 30 min verhindern können. Beim HTTPMOD kann man das nicht. Möchte nicht wissen wie viele Leute das auf 60s oder so von Hand gestellt haben.

[supernova1963]

Da kann ich mich nur bei der schnellen Reaktion der Profis bedanken, denn ich weiß nicht ob die Nutzer es wirklich löschen.

@Cooltux: Ich habe mir deinen Vorschlag gesichert und werde, sobald ich etwas mehr Zeit habe, auch versuchen deinen Änderungen zu verstehen. Ich habe dennoch den git gelöscht, da die HTTPMOD's auch nach deinen Änderungen noch angelegt wurden und aktiv waren. Ich hätte erst in meinem kommenden Urlaub in 10 Tagen ausreichend Zeit gefunden mich mit den notwendigen Änderungen zu beschäftigen. Aufgrund dieser unvermeidlichen Tatsache und deiner Information zu drohendem Ärger halte ich es für richtig das ganze erstmal zu stoppen und, - wenn möglich -, in Ruhe nachzubessern.

[CoolTux]

Bei Fragen schreib mich einfach an.


Grüße

[supernova1963]

Danke, mach ich gerne.

[betateilchen]

Aus aktuellen Anlass habe ich die halb-implementierte Komprimierung in HttpUtils zu Ende programmiert und aktiviert. Falls jemand damit Probleme hat, bitte melden, bis zu einem Fix kann man als workaround "attr global httpcompress 0" setzen.

Hallo Rudi, ich bin heute auf die erste Webseite gestoßen, bei der HTTPMOD mit der global aktivierten compress nicht zurechtkommt. Nachdem ich das Attribut httpcompress auf 0 gesetzt habe, ist alles gut.

Details folgen.