HttpUtils aktiviert ab sofort die Komprimierung

[rudolfkoenig]

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.

Anlass: ein Mitarbeiter eines Providers fuer ein Verlagshaus hat angerufen, und meldete, dass FHEM-Benutzer mit HTTPMOD beim Abruf des TV-Programms Datenverkehr im Terabyte-Bereich generieren, und man haette gerne das Volumen reduziert. Er sprach von einem Wiki-Artikel, den ich jetzt auf Anhieb nicht gefunden habe. Da sollte definitiv erwaehnt werden, dass ein Abruf der Seite alle 30 Sekunden sinnlos sei, und evtl durch eine Sperrung vom Anbieter allen FHEM-Benutzer schaden koennte.

Auch update profitiert etwas davon, allerdings werden die meisten Dateien noch unkomprimiert ausgeliefert, obwohl komprimiert bestellt wurden. Komprimiert wird fhem.pl, MAINTAINER.txt, alle .js Dateien aber nicht CHANGED, FHEM/*.pm, *.svg. Ich habe jetzt eine Weile ueber die Apache-Konfiguration und .htaccess Dateien meditiert, bin aber nicht klueger geworden. Wenn jemand noch Tipps fuer die Fehlersuche hat, bitte melden.

[Wernieman]

Bezüglich apache-config:

Könnte Dir anbieten, selber darüber zu schauen, nur müsste dafür die apache-config bekannt sein.

Habe aber bezüglich der Komprimierung schon positive/negative Erfahrungen gemacht ...

[CoolTux]

Klingt nach http://www.klack.de

Da ist gerade ein User dabei was zu programmieren. Leider recht umständlich mit mehreren HTTPMOD Devices und entsprechenden abrufen pro Sender. Bin aktuell dabei das gerade zu ziehen mit einem Masterdevice zu entwickeln was die Daten dann vor hält für die eigentlichen Senderdevices.



Grüße

[herrmannj]

ja, ja. Ein Terabyte hier, ein terabyte dort... mit der Zeit kommt über den Tag verteilt einiges zusammen.

Bieten die komplette Filme an ? Terabyte(s) an TV Daten ? echt jetzt ?

[CoolTux]

Wenn es das ist was ich denke dann bieten die TV Programminformationen an.
Es saugen aber auch eine Menge Leute und das mehrmals pro Minute 

[betateilchen]

Da sollte definitiv erwaehnt werden, dass ein Abruf der Seite alle 30 Sekunden sinnlos sei, und evtl durch eine Sperrung vom Anbieter allen FHEM-Benutzer schaden koennte.

Ich wäre sehr dafür, dass der Anbieter diese Sperre aktiviert. Dann hört der Schwachsinn mit den viel zu häufigen Aufrufen an irgendwelche URLs vielleicht endlich mal auf.

Auf debian.fhem.de habe ich aktuell pro Tag über 100.000 Abrufe der repository Infos, davon fast 10.000 von der gleichen IP. Das heißt, irgendjemand "prüft" alle 10 Sekunden, ob sich etwas geändert hat. Und das, obwohl das Repository nur einmal pro Tag aktualisiert wird.

[betateilchen]

Er sprach von einem Wiki-Artikel, den ich jetzt auf Anhieb nicht gefunden habe.

https://github.com/supernova1963/TVSender/wiki

(Vermutung)

[rudolfkoenig]

Könnte Dir anbieten, selber darüber zu schauen, nur müsste dafür die apache-config bekannt sein.

Danke fuers Angebot, ich habe dir eine Email mit Daten geschickt.

[CoolTux]

https://github.com/supernova1963/TVSender/wiki

(Vermutung)

Vermutung passt

[betateilchen]

Wieviel Volumen würde bei der Komprimierung von 1 TB TV-Programmdaten tatsächlich eingespart?

[rudolfkoenig]

Na das haengt vom Inhalt ab, der Herr sprach von 70kb statt 600kb bei der betroffenen Seite (wenn ich mich recht erinnere, war nicht ganz wach ), was mir allerdings bei gzip (das einzige, was wir z.Zt. unterstuetzen) schon etwas hoch vorkommt.

[betateilchen]

als statt 10 TB dann "nur" noch eines... 

[CoolTux]

Ich habe soeben meinen Teil für dieses Modul ins Git des Maintainers geladen. Es werden alle 30 min vom Master Device 2 URLs abgerufen und die Daten im $hash->{helper}{buf} vorgehalten. Nun müssen nur noch die Sender Devices sich die Daten vom Master holen und gut ist. Sollte also bald ruhiger werden.

[betateilchen]

Wozu muss man ein Fernsehprogramm alle 30 Minuten vom Server holen?

[CoolTux]

Das war jetzt erstmal eine grobe Richtung. Was weiß ich. Das kann man ja auch noch ändern. Ich kenne nicht mal den Inhalt der Daten. Wollte nur erstmal schnell das dem armen Jungen irgendwie geholfen wird.
Ich verwende das noch nicht mal

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