gzip-Komprimierung

[Pit]

Guten Morgen,

ich lese des öfteren, man soll seine Webseiten gzip-komprimiert ausliefern.

Wie ich aus dem Archiv entnommen habe, hat das was mit dem Apache zu tun.

Wie kann ich rausfinden, ob der Apache bei Purectec so was kann, habe ja keinen Zugriff auf das Teil, und auch in deren Doku finde ich nichts, was mir weiterhilft ?

Muss ich in meine HTML-Seiten irgenwas reinschreiben ?

Was muss ich in meine PHP-Seiten reinschreiben ?

Pit

[Sönke Tesch]

ich lese des öfteren, man soll seine Webseiten gzip-komprimiert ausliefern.

Es ist durchaus sinnvoll, statt 80 kByte roh 8 kByte komprimiert zu liefern.

Wie kann ich rausfinden, ob der Apache bei Purectec so was kann, habe ja keinen Zugriff auf das Teil, und auch in deren Doku finde ich nichts, was mir weiterhilft ?

Da PHP zu haben scheinst: Ein Aufruf von phpinfo() verrät Dir, ob das Modul mod_gzip im Server steckt.

Die 100%-ig sichere Prüf-Methode:
Sinnvollerweise sollte das Modul schon von der Hauptkonfiguration des Servers her eingeschaltet sein. Willst Du aber ganz sicher gehen, kannst Du mittels telnet (auf allen Systemen, auch Windows, standardmäßig vorhanden) probeweise eine Seite abrufen:

• Verbindung zu Deinem Server, Port 80.
• "GET www.dein.server.name/ HTTP/1.0" + Return eintippen (ohne Anführungszeichen)
• "Accept-Encoding: gzip" + Return eintippen (auch ohne Tütelchen)
• Return drücken (also eine Leerzeile hinterherschicken)

Als Ergebnis sollte Zeichensalat (=komprimierte Daten) auf Deinem Bildschirm erscheinen. Wenn Du schnell genug bist (oder die Logging-Funktion von telnet eingeschaltet hast), kannst Du über dem Salat noch einige Zeilen lesen (Kopfzeilen oder Header), etwa so:

HTTP/1.0 200 Ok
  Server: Apache sowieso
  bla: blablabla
  Content-Encoding: gzip
  nochmehr: blabla

DatenDatenfrischvomFeld

Wichtig: Die Content-Encoding-Zeile.

Muss ich in meine HTML-Seiten irgenwas reinschreiben ?

Nein.

Was muss ich in meine PHP-Seiten reinschreiben ?

Nein.

Für alles weitere: http://forum.de.selfhtml.org/archiv/2002/9/25053/#m137605.

Gruß,
  soenk.e

[Pit]

Da PHP zu haben scheinst: Ein Aufruf von phpinfo() verrät Dir, ob das Modul mod_gzip im Server steckt.

Habe ich gemacht, hier alles was ich mit gzip gefunden habe:

HTTP_ACCEPT_ENCODING gzip, deflate
_SERVER["HTTP_ACCEPT_ENCODING"] gzip, deflate
_ENV["HTTP_ACCEPT_ENCODING"] gzip, deflate

Ist das mod_gzip ?

Muss ich in meine HTML-Seiten irgenwas reinschreiben ?

Nein.

Was muss ich in meine PHP-Seiten reinschreiben ?

Nein.

Erspart mir doch eine Menge Arbeit ;-)
( Falls das oben mod_gzip ist. )

Pit

[PeterK]

mod_gzip ist das Ding, dass dem Apache sagt wann er das Archiv un wann er die normale Seite schicken soll. (ganz grob gesagt)

PeterK

[Andreas Korthaus]

Hi!

mod_gzip ist das Ding, dass dem Apache sagt wann er das Archiv un wann er die normale Seite schicken soll. (ganz grob gesagt)

Komprimiert mod_gzip nicht "nur" den Content, also wenn der Client gzip unterstützt und einen entsprechenden Header sendet, wird die "html" - Datei komptimiert ausgeliefert, sonst halt normal als html.

Kann mich aber auch irren!

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

mod_gzip ist das Ding, dass dem Apache sagt wann
er das Archiv un wann er die normale Seite schicken
soll. (ganz grob gesagt)
Komprimiert mod_gzip nicht "nur" den Content,

beides, und noch ca. ein Dutzend weiterer Dinge.

Es hat schon seinen Grund, warum der Quelltext von mod_gzip 1.3.26.1a über 12000 Zeilen lang ist.

Viele Grüße
      Michael

[Andreas Korthaus]

Hallo!

beides, und noch ca. ein Dutzend weiterer Dinge.

Es hat schon seinen Grund, warum der Quelltext von mod_gzip 1.3.26.1a

hat das was mit der Apache-Version zu tun?

über 12000 Zeilen lang ist.

Ich wollte meinen provider auch mal dazu bewegen das zu installieren, aber er hat entschieden abgeblockt. zum einen vermute ich das Argument das das Sparen an Traffic für die Kunden zum einen die Traffic-Einnahmen schmälert, zum anderen auf Kosten der Performance geht.
zumindest letzteres hat er auch gesagt, denn dr Aoache ist fpalle Kunden glech konfiguuriert, und wenn die Seiten alle Kunden durch mod_gzip gehen sei da schon ein erheblicher Performace-Nachteil, den man durch zusäztliche Hardware ausgleichen müßte, des weitern gäbe es bei dynamischen Seiten mit Hilfe der Ausgabesteuerung Möglichkeiten das dort zu erledigen, und bei statischen Seiten die Möglichkeit mit multiview je eine .html.gz und eine .html in einem Cache-Verzeicnis zu speichern und entsprechend dem Request-Header auszuliefern.

Was meinst Du dazu?

Viele Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

Ich wollte meinen provider auch mal dazu bewegen
das zu installieren, aber er hat entschieden
abgeblockt.

meiner auch - deshalb haben Christian und ich ja gzip_cnc geschrieben ...

zum einen vermute ich das Argument das das Sparen
an Traffic für die Kunden zum einen die Traffic-
Einnahmen schmälert,

Das Gegenteil ist der Fall. Der Provider würde dadurch _mehr_ Geld verdienen - wenn er weiß, was er tut.

zum anderen auf Kosten der Performance geht.

Auch das ist nicht der Fall - wenn man mod_gzip mit Bedacht einsetzt.
Natürlich ist es Unfug, beispielsweise GIF-Dateien zu komprimieren, die dabei kaum kleiner und schlimmstenfalls sogar größer werden könnten. Man muß halt wissen, was man erreichen will.
In unserer Serverfarm werden etwa 40% aller Requests komprimiert - aber diese Dateien machen 85% des gesamten Brutto-Traffic aus.

Ich bin mir allerdings bewußt, daß die aktuelle mod_gzip-Version dem Provider keine sinnvolle Möglichkeit gibt, Dir nur einen Teil der Funktionalität von mod_gzip freizuschalten - es gibt keine Bindung von mod_gzip-Direktiven an irgendwelche Berechtigungskonzepte des Apache, beispielsweise an "Options" oder "AllowOverride". Wenn mod_gzip geladen ist, dann darfst Du alles einschalten, was mod_gzip kann.
Er müßte Dir also vertrauen, daß Du eine sinnvolle Konfiguration dafür schreibst. Oder er müßte bestimmte mod_gzip-Direktiven aus dem Quelltext ausbauen.
Vielleicht müßte man die Verwendung von mod_gzip in .htaccess-Dateien verbieten, so daß der Provider dann nach Deinen Angaben ein paar Direktiven in Deinen Virtual Host eintragen müßte. Dann aber wären die Konfigurationen seiner Kunden nicht mehr identisch ...

zumindest letzteres hat er auch gesagt,
denn der Aoache ist für alle Kunden gleich
konfiguriert,

Das würde auch beim Einsatz von mod_gzip mit Konfiguration via .htaccess so bleiben.

Der Provider halt die Wahl: Entweder volle Kontrolle, oder eigene Arbeit. Oder kein mod_gzip.

und wenn die Seiten alle Kunden durch mod_gzip gehen

Wer hat das behauptet? Das wäre weder notwendig noch sinnvoll.
Sorry, aber wenn Dein Provider zu faul ist, meine Dokumentation zu lesen, dann such Dir einen anderen. (Was ich ohne gzip_cnc auch tun würde.)

sei da schon ein erheblicher Performace-Nachteil,

Das ist in dieser Pauschalität auch nicht wahr.
Ein gut konfiguriertes mod_gzip würde die Maschine _schneller_ machen, nicht langsamer.

den man durch zusätzliche Hardware ausgleichen
müßte,

Siehe oben.

des weitern gäbe es bei dynamischen Seiten mit Hilfe
der Ausgabesteuerung Möglichkeiten das dort zu
erledigen

Der Provider ist also unfähig, Dir einen guten Servive zu bieten, und fordert Dich auf, Deine gesamten Seiten auf dynamisch umzustellen und _dadurch_ massiv (!) zusätzliche Last auf seinen (!) Server zu bringen?
Weiß dieser Provider eigentlich, was er da sagt?
Was immer Du selbst programmieren könntest - so performant wie mod_gzip kriegst Du das nicht hin.

Du kannst natürlich gerne das tun, was er Dir vorschlägt (nämlich gzip_cnc einsetzen) ...

und bei statischen Seiten die Möglichkeit mit
multiview je eine .html.gz und eine .html in einem
Cache-Verzeicnis zu speichern und entsprechend dem
Request-Header auszuliefern.

Ja. Aber genau das kann mod_gzip natürlich auch, und _viel_ besser.
Beispielsweise müßtest Du Deine .gz-Dateien manuell aktualisieren, wenn ihr Inhalt veraltet ist - mod_gzip würde das automatisch erkennen - und mod_gzip 1.3.26.1a würde Deine .gz-Dateien automatisch aktualisieren!

Und außerdem müßtest Du bei normaler Negotiation alle Deine Links anpassen, wie Sven richtig angemerkt hat. mod_gzip würde Dir das ersparen - und gzip_cnc ebenfalls.

Was meinst Du dazu?

RTFM. Am besten beide.

Viele Grüße
      Michael

[Andreas Korthaus]

Da PHP zu haben scheinst: Ein Aufruf von phpinfo() verrät Dir, ob das Modul mod_gzip im Server steckt.

Habe ich gemacht, hier alles was ich mit gzip gefunden habe:

HTTP_ACCEPT_ENCODING gzip, deflate
_SERVER["HTTP_ACCEPT_ENCODING"] gzip, deflate
_ENV["HTTP_ACCEPT_ENCODING"] gzip, deflate

Ist das mod_gzip ?

nein, das ist nur die Umgebungsvariabe in der steht ob der Browser komprimierte Daten lesen kann!

Grüße
Andreas

[Sönke Tesch]

Da PHP zu haben scheinst: Ein Aufruf von phpinfo() verrät Dir, ob das Modul mod_gzip im Server steckt.

Habe ich gemacht, hier alles was ich mit gzip gefunden habe:

HTTP_ACCEPT_ENCODING gzip, deflate
_SERVER["HTTP_ACCEPT_ENCODING"] gzip, deflate
_ENV["HTTP_ACCEPT_ENCODING"] gzip, deflate

Ist das mod_gzip ?

Nein, mod_gzip ist nur da drin, wo auch mod_gzip drauf steht :) Irgendwo in der phpinfo()-Ausgabe wirst Du einen ganzen Bandwurm mod_irgendwas finden, da müsste auch ein mod_gzip drin sein:

Apache

Loaded Modules mod_php4, mod_gzip, mod_fastcgi, mod_frontpage, mod_perl,
                 mod_ssl, mod_setenvif, mod_so, mod_headers, usw.

Die drei von Dir zitierten Zeilen stellen (wie hier bereits gesagte wurde) allesamt die Accept-Encoding:-Kopfzeile dar (bzw. die Variablen, die PHP Dir zur Verfügung stellt), die der Browser gesendet hat, um dem Server seine Kenntnisse mitzuteilen.

Gruß,
  soenk.e

[Andreas Korthaus]

Hi!

Nein, mod_gzip ist nur da drin, wo auch mod_gzip drauf steht :) Irgendwo in der phpinfo()-Ausgabe wirst Du einen ganzen Bandwurm mod_irgendwas finden, da müsste auch ein mod_gzip drin sein:

Apache

Loaded Modules mod_php4, mod_gzip, mod_fastcgi, mod_frontpage, mod_perl,
                 mod_ssl, mod_setenvif, mod_so, mod_headers, usw.

Das habe ich schon oft gehört aber noch nie finden können ?!
Kann es sein das das nur die Modul-Version von PHP anzeigen kann? das einzige was ich (in meiner CGI-Version) habe ist :

Environment

SERVER_SOFTWARE Apache/df-exts 1.1 (Unix) mod_ssl/2.8.11
                OpenSSL/0.9.6e AuthPG/1.2 FrontPage/5.0.2.2510

Grüße
Andreas

[Sönke Tesch]

Loaded Modules mod_php4, mod_gzip, mod_fastcgi, mod_frontpage, mod_perl,
                 mod_ssl, mod_setenvif, mod_so, mod_headers, usw.

Das habe ich schon oft gehört aber noch nie finden können ?!
Kann es sein das das nur die Modul-Version von PHP anzeigen kann? das einzige was ich (in meiner CGI-Version) habe ist :

Das wäre angesichts der Art und Weise, wie die CGI-Schnittstelle funktioniert, mehr als wahrscheinlich.

Environment

SERVER_SOFTWARE Apache/df-exts 1.1 (Unix) mod_ssl/2.8.11
                OpenSSL/0.9.6e AuthPG/1.2 FrontPage/5.0.2.2510

Da taucht sollte es sich allerdings auch verewigen, sofern diese Anezeige nicht im Server abgeschaltet wurde (wie man sieht nicht) und auch nicht im Modul selber (AFAIK nicht möglich).

Die 100%-ig sichere Methode ist wie gesagt immernoch eine HTTP-Anfrage per telnet.

Gruß,
  soenk.e

[Christian Seiler]

Hallo,

ich lese des öfteren, man soll seine Webseiten gzip-komprimiert ausliefern.

Es fördert die Übertragungsrate.

Wie ich aus dem Archiv entnommen habe, hat das was mit dem Apache zu tun.

Exakt.

Wie kann ich rausfinden, ob der Apache bei Purectec so was kann, habe ja keinen Zugriff auf das Teil, und auch in deren Doku finde ich nichts, was mir weiterhilft ?

Wenn Du bei deinem Provider mod_gzip nicht aktivieren kannst (frag' ihn einfach mal) dann gibt es immernoch eine Alternative: http://www.schroepl.net/projekte/gzip_cnc/

Muss ich in meine HTML-Seiten irgenwas reinschreiben ?

Nein.

Was muss ich in meine PHP-Seiten reinschreiben ?

Wenn Du am Ende doch noch mod_gzip bekommst, nichts. Wenn nicht, dann kann man bei PHP über sog. Output Buffering Handler das Resultat auch komprimieren. Die Frage ist jedoch: lohnt sich das? Wie groß sind Deine PHP-Seiten?

http://www.php.net/manual/en/function.ob-gzhandler.php

Beachte, dass ob_gzhandler immer Komprimiert, daher solltest Du unbedingt den Accept-Encoding-Header vom Browser parsen, bevor Du damit anfängst.

Grüße,

Christian

[Andreas Korthaus]

Hallo!

http://www.php.net/manual/en/function.ob-gzhandler.php

Beachte, dass ob_gzhandler immer Komprimiert, daher solltest Du unbedingt den Accept-Encoding-Header vom Browser parsen, bevor Du damit anfängst.

Da steht aber

Before ob_gzhandler() actually sends compressed data, it determines what type of content encoding the browser will accept ("gzip", "deflate" or none at all) and will return it's output accordingly. All browsers are supported since it's up to the browser to send the correct header saying that it accepts compressed web pages.

Grüße
Andreas

[Sönke Tesch]

http://www.php.net/manual/en/function.ob-gzhandler.php

Beachte, dass ob_gzhandler immer Komprimiert, daher solltest Du unbedingt den Accept-Encoding-Header vom Browser parsen, bevor Du damit anfängst.

Da steht aber

Before ob_gzhandler() actually sends compressed data, it determines what type of content encoding the browser will accept ("gzip", "deflate" or none at all) and will return it's output accordingly. All browsers are supported since it's up to the browser to send the correct header saying that it accepts compressed web pages.

Und wenn ich mich nicht irre, wurde obendrein zumindest in früheren PHP-Anleitungen vor der Benutzung von ob_gzhandler explizit gewarnt, weil das Ding alles andere als zuverlässig funktionierte. Deshalb besser zlib.out_compression.

Gruß,
  soenk.e

[Andreas Korthaus]

Hi!

Before ob_gzhandler() actually sends compressed data, it determines what type of content encoding the browser will accept ("gzip", "deflate" or none at all) and will return it's output accordingly. All browsers are supported since it's up to the browser to send the correct header saying that it accepts compressed web pages.

Und wenn ich mich nicht irre, wurde obendrein zumindest in früheren PHP-Anleitungen vor der Benutzung von ob_gzhandler explizit gewarnt, weil das Ding alles andere als zuverlässig funktionierte. Deshalb besser zlib.out_compression.

http://www.php.net/manual/en/function.ob-gzhandler.php

wo denn?

Grüße
Andreas

[Pit]

Ich möchte mich bei allen ganz herzlich bedanken für die wertvollen Infos- DANKE.

Was ich nicht so ganz verstehe, warum Provider, die ja wohl auch an einer Verringerung des Traffics interessiert sind, wer verbraucht schon mehr als den im Paket enthaltenen Traffic, ich glaube nicht sehr viele, bei der Auswahl des Paketes spielen doch viel mehr die anderen Features eine Rolle, die beim kleineren Paket nicht drin sind, PHP MySQL SSL etc., nicht standardmäßig mod_gzip laufen lassen ?

Werde meine Provider morgen mal anmailen, vielleicht läuft ja auch schon mod_zip, und ich weiss es nicht, aber ich glaube eher nicht, da in der phpinfo() nichts von mod_zip steht:

'./configure' '--with-mysql=/usr' '--with-zlib' '--enable-debug=no' '--enable-safe-mode=no' '--enable-discard-path=no' '--with-gd' '--with-png-dir=/usr/local/lib' '--enable-track-vars' '--with-db' '--with-gdbm' '--enable-force-cgi-redirect' '--with-ttf=/usr/src/kundenserver/freetype-1.2/' '--enable-ftp' '--with-mcrypt' '--enable-dbase' '--enable-memory-limit' '--enable-calendar' '--enable-wddx' '--enable-trans-sid' '--with-jpeg-dir=/usr/src/kundenserver/jpeg-6b' '--enable-bcmath' '--enable-gd-imgstrttf' '--enable-shmop' '--enable-mhash' '--with-mhash=/usr/src/kundenserver/mhash-0.8.9/' '--with-openssl' '--enable-xslt' '--with-xslt-sablot' '--with-imap' '--with-curl' '--with-iconv'

Pit

[Andreas Korthaus]

Hallo!

Was ich nicht so ganz verstehe, warum Provider, die ja wohl auch an einer Verringerung des Traffics interessiert sind,

Ja? Wieso? Die verdienen jawohl an jedem MB Traffic extra! Oder brauchst Du den Traffic nicht bezahlen?

wer verbraucht schon mehr als den im Paket enthaltenen Traffic, ich glaube nicht sehr viele,

naja...

bei der Auswahl des Paketes spielen doch viel mehr die anderen Features eine Rolle, die beim kleineren Paket nicht drin sind, PHP MySQL SSL etc., nicht standardmäßig mod_gzip laufen lassen ?

mod_gzip kennen die meisten potetnteillen Kunden der Massenhoster eh nicht, also warum sich diesen Klotz ans Bein binden, denn mod_gzip ist durchaus eine höhere Serverbelastung, was bei gleibleibender Performance mehr Server benötigt, und die kosten Geld...

Werde meine Provider morgen mal anmailen, vielleicht läuft ja auch schon mod_zip, und ich weiss es nicht,

das ist im Zweifel meist das einfachste, noch schneller ist ein Gespräch!

aber ich glaube eher nicht, da in der phpinfo() nichts von mod_zip steht:

'./configure' '--with-mysql=/usr' '--with-zlib' '--enable-debug=no' '--enable-safe-mode=no' '--enable-discard-path=no' '--with-gd' '--with-png-dir=/usr/local/lib' '--enable-track-vars' '--with-db' '--with-gdbm' '--enable-force-cgi-redirect' '--with-ttf=/usr/src/kundenserver/freetype-1.2/' '--enable-ftp' '--with-mcrypt' '--enable-dbase' '--enable-memory-limit' '--enable-calendar' '--enable-wddx' '--enable-trans-sid' '--with-jpeg-dir=/usr/src/kundenserver/jpeg-6b' '--enable-bcmath' '--enable-gd-imgstrttf' '--enable-shmop' '--enable-mhash' '--with-mhash=/usr/src/kundenserver/mhash-0.8.9/' '--with-openssl' '--enable-xslt' '--with-xslt-sablot' '--with-imap' '--with-curl' '--with-iconv'

Wenn ich nicht irre ist das die Konfiguration von PHP, halt welche Module hier gestartet bzw. einkompiliert wurden, hat herzlich wenig mit Apache zu tun!

Grüße
Andreas

[Pit]

Hallo!

Auch Dir wünsch' ich einen schönen Abend !

Was ich nicht so ganz verstehe, warum Provider, die ja wohl auch an einer Verringerung des Traffics interessiert sind,
Ja? Wieso? Die verdienen jawohl an jedem MB Traffic extra! Oder brauchst Du den Traffic nicht bezahlen?

Ich habe 25 GB frei, das langt mir.

Nur ein einziger mir Bekannter hat mal mehr Traffic verbraten als er hat, und da er keine Lust hatte mehr zu zahlen, hat er alle seine Bilderchen auf Freespace-Provider ausgelagert, für Bilderchen sind diese Server mit ihrer Anbindung gut genug, das macht er jetzt schon über ein Jahr und es klappt bei ihm.

'./configure' '--with-mysql=/usr' '--with-zlib' '--enable-debug=no' '--enable-safe-mode=no' '--enable-discard-path=no' '--with-

Wenn ich nicht irre ist das die Konfiguration von PHP, halt welche Module hier gestartet bzw. einkompiliert wurden, hat herzlich wenig mit Apache zu tun!

Ach so.
Sönke Tesch schrieb vorhin: "Da PHP zu haben scheinst: Ein Aufruf von phpinfo() verrät Dir, ob das Modul mod_gzip im Server steckt."
Aber bei steht nirgends was von mod_gzip.

Grüße
Andreas

Pit

[Andreas Korthaus]

Hallo!

Ach so.
Sönke Tesch schrieb vorhin: "Da PHP zu haben scheinst: Ein Aufruf von phpinfo() verrät Dir, ob das Modul mod_gzip im Server steckt."
Aber bei steht nirgends was von mod_gzip.

Ja, das Problem hab ich ebenfalls! Was Du gerade aus der phpinfo() zitiert hast war wohl

"Configure Command"

oder? Darunter müßte bei Dir

"Server API" stehen, wenn da "CGI" steht vermute ich das das wirklich nur in der Modul-Version angezeigt wird, denn nur da hatte ich bisher ein Segment "Apache" .

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

Was ich nicht so ganz verstehe, warum Provider,
die ja wohl auch an einer Verringerung des
Traffics interessiert sind,
Ja? Wieso? Die verdienen jawohl an jedem MB Traffic
extra! Oder brauchst Du den Traffic nicht bezahlen?

(Fast) kein Provider besitzt ein eigenes Internet-Backbone. Sie müssen also die Auffahrt zur Daten-Autobahn einkaufen.
Es wäre für jeden Provider _dringend_ zu empfehlen, komprimierte Daten auszuliefern.

Das pricing kann er dann ja einerseits auf den Bruttodaten (vor Komprimierung) basieren lassen, um vergleichbare Preise zur Konkurrenz zu bieten - er kann aber auch billigere Preise anbieten (z. B. 30% günstiger), wenn er beim Einkauf durch die Komprimierung 50% sparen kann.

Wäre ich ein Provider, dann würde ich allerdings Preispakete auf Netto-Traffic basieren lassen, dann etwas höher als bei der Konkurrenz, aber den Kunden erklären, wieso das für _sie_ trotzdem besser ist.

Das Problem ist in jedem Fall, daß der Provider nicht entscheiden _sollte_, welche Seiten komprimiert ausgeliefert werden.
Meiner Meinung nach _muß_ das der Seitenanbieter entscheiden - weil angesichts der zahlreichen kaputten Browser (ungefähr 99% aller verfügbaren, inklusiver aller M$IE und aller Mozillas!) nur dieser selbst entscheiden kann, welche Risiken er einzugehen bereit ist.
Ich würde als Provider mod_gzip also laden, nicht aber einschalten, und den Kunden erklären, wie sie via .htaccess eine ihren Wünschen entsprechende Konfiguration schreiben können, _um_ dadurch ihren Traffic-Preis zu reduzieren.

wer verbraucht schon mehr als den im Paket
enthaltenen Traffic, ich glaube nicht sehr
viele, naja...

Eben. Um so mehr muß der Provider aber daran interessiert sein, daß die Daten komprimiert ausgeliefert werden! Die Kunden zahlen ja immer noch den Paketpreis, der Provider muß aber weniger Bandbreite einkaufen!
Und "nebenbei" hat er auch noch zufriedenere Kunden, weil deren Seiten schnellere Antwortzeiten haben.

mod_gzip kennen die meisten potetnteillen Kunden
der Massenhoster eh nicht, also warum sich diesen
Klotz ans Bein binden, denn mod_gzip ist durchaus
eine höhere Serverbelastung, was bei gleibleibender
Performance mehr Server benötigt, und die kosten
Geld...

Die Bandbreite kostet viel mehr zusätzliches Geld. mod_gzip erzeugt zwar zusätzliche CPU-Last beim Komprimieren, aber es _spart_ auch CPU-Last beim Senden der Daten durch die TCP/IP-Schnittstelle.
Es hängt von der Verteilung der Seitenzugriffe ab, ob das nicht in der Summe sogar zu einer _Entlastung_ des Servers führt.

Und all dies gilt zudem nur, wenn _alle_ Seiten dynamisch komprimiert werden müssen!
Das ist aber nicht der Fall - die komprimierten Seiten können gecached werden (wahlweise in einem Proxy oder in Form vorkomprimierter statischer Parallel-Versionen - beides wird hier im Self-Portal praktiziert) und müssen dann jeweils nur noch ein einziges Mal komprimiert werde, für beliebig viele Lesezugriffe.

'./configure' '--with-mysql=/usr' '--with-zlib'

Wer braucht denn diese zlib? Du weißt, daß das genau die Bibliothek ist, welche eine gzip-Komprimierung durchführen kann?
(Allerdings hat mod_1.3 gzip seine eigene gzip-Implementierung und nutzt die normale zlib nicht.)

Viele Grüße
      Michael

[Andreas Korthaus]

Hi!

vorab: Sorry für die vielen Tippfehler, ich gelobe Besserung ;-)

(Fast) kein Provider besitzt ein eigenes Internet-Backbone. Sie müssen also die Auffahrt zur Daten-Autobahn einkaufen.

klar!

Es wäre für jeden Provider _dringend_ zu empfehlen, komprimierte Daten auszuliefern.

naja, aber nur wenn es tatsächlich so gut wie keine
Mehrbelastung ist. Denn die geben die Kosten für den traffic ja nicht 1:1 an die Kunden weiter, wenn die für ein GB 10 Cent bezahlen, bezahlt der Kunde vermutlich 20 oder 25 oder noch mehr(habe keine Ahnung von den Preisen).
Wenn denn jetzt 70% Traffic eingespart wid, ist das ja wirklich prima für die Kunden, aber dem provider entgehen 70% der Einnahmen aus der Weiterverkauf der Bandbreite. Das sind rein wirtschaftliche Interessen. Ich weiß auch nicht ob Den pricing-System rechtlich so einwandfrei ist, denn Du berechnest ja eigentlich zu viel Traffic, da werden sich wohl diejenigen die das eh so gemacht hätten beschweren, denn jetzt haben alle DAUs denselben Vorteil.

Das pricing kann er dann ja einerseits auf den Bruttodaten (vor Komprimierung) basieren lassen, um vergleichbare Preise zur Konkurrenz zu bieten - er kann aber auch billigere Preise anbieten (z. B. 30% günstiger), wenn er beim Einkauf durch die Komprimierung 50% sparen kann.

Wobei mir gerade einfällt, 70% war wohl übertrieben, man muß ja sehen das ein großer Teil der Daten ja kleine html-Dateien sind und vor allem Bilder! Und die kann man so gut wie nicht komprimieren!

Wäre ich ein Provider, dann würde ich allerdings Preispakete auf Netto-Traffic basieren lassen, dann etwas höher als bei der Konkurrenz, aber den Kunden erklären, wieso das für _sie_ trotzdem besser ist.

jaja, aber damit entgehen ihm vermutlich einige Kunden, die wenig Ahnung haben!

Das Problem ist in jedem Fall, daß der Provider nicht entscheiden _sollte_, welche Seiten komprimiert ausgeliefert werden.
Meiner Meinung nach _muß_ das der Seitenanbieter entscheiden - weil angesichts der zahlreichen kaputten Browser (ungefähr 99% aller verfügbaren, inklusiver aller M$IE und aller Mozillas!) nur dieser selbst entscheiden kann, welche Risiken er einzugehen bereit ist.
Ich würde als Provider mod_gzip also laden, nicht aber einschalten, und den Kunden erklären, wie sie via .htaccess eine ihren Wünschen entsprechende Konfiguration schreiben können, _um_ dadurch ihren Traffic-Preis zu reduzieren.

Genau das ist es was ich wollte, aber der Provier meinte halt es gäbe bereits gute Lösungen(multiview/Ausgabesteuerung), so dass dies wieder nur einen Performance-Verlust zur Folge hätte für nichts und wieder nichts. Wenn das den so geladen und _nicht_ benutzt wird, kostet das denn dann überhaut was?

wer verbraucht schon mehr als den im Paket
enthaltenen Traffic, ich glaube nicht sehr
viele, naja...

Eben. Um so mehr muß der Provider aber daran interessiert sein, daß die Daten komprimiert ausgeliefert werden! Die Kunden zahlen ja immer noch den Paketpreis, der Provider muß aber weniger Bandbreite einkaufen!

ja aber wenn das alles so einfach wäre, warum macht das keiner? Ich denke Du hast das Problem genannt, das sollte Sache der Kunden sein, und welcher Kunde der unter dem Limit bleibt schert sich um sowas?

Und "nebenbei" hat er auch noch zufriedenere Kunden, weil deren Seiten schnellere Antwortzeiten haben.

das ist ein Argument

mod_gzip kennen die meisten potetnteillen Kunden
der Massenhoster eh nicht, also warum sich diesen
Klotz ans Bein binden, denn mod_gzip ist durchaus
eine höhere Serverbelastung, was bei gleibleibender
Performance mehr Server benötigt, und die kosten
Geld...

Die Bandbreite kostet viel mehr zusätzliches Geld. mod_gzip erzeugt zwar zusätzliche CPU-Last beim Komprimieren, aber es _spart_ auch CPU-Last beim Senden der Daten durch die TCP/IP-Schnittstelle.
Es hängt von der Verteilung der Seitenzugriffe ab, ob das nicht in der Summe sogar zu einer _Entlastung_ des Servers führt.

Meinst Du wirklich? Das senden kostet doch nun wirklich nicht viel, komprimieren ist doch ganz was anderes, oder komprimiert mod_gzip nicht immer _alles_ zur Laufzeit? Gibt es da auch einen cache? Aber das funktiniert wieder schlecht mit dynamischen Seiten.

Und all dies gilt zudem nur, wenn _alle_ Seiten dynamisch komprimiert werden müssen!
Das ist aber nicht der Fall - die komprimierten Seiten können gecached werden (wahlweise in einem Proxy oder in Form vorkomprimierter statischer Parallel-Versionen - beides wird hier im Self-Portal praktiziert) und müssen dann jeweils nur noch ein einziges Mal komprimiert werde, für beliebig viele Lesezugriffe.

Aber das macht mod_gezip doch nicht alleine, oder? Dazu braucht es doch noch entsprechende Software!

'./configure' '--with-mysql=/usr' '--with-zlib'

Wer braucht denn diese zlib? Du weißt, daß das genau die Bibliothek ist, welche eine gzip-Komprimierung durchführen kann?

Sehr wohl, habe ich letzte Woche exzessiv betrieben ;-) Aber das ist halt nur das PHP-Modul welches einkompiliert wurde, das hat mit dem Apachen ja nichts zu tun!

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

naja, aber nur wenn es tatsächlich so gut wie keine
Mehrbelastung ist. Denn die geben die Kosten für den
traffic ja nicht 1:1 an die Kunden weiter, wenn die
für ein GB 10 Cent bezahlen, bezahlt der Kunde
vermutlich 20 oder 25 oder noch mehr(habe keine
Ahnung von den Preisen).

wenn der Provider den Brutto-Traffic bepreist, dann spart _er_ Geld, der Kunde bezahlt dasselbe, der Gewinn ist also höher, _und_ der Kunde halt schneller ausgelieferte Seiten. Also?
Dies gilt sowohl für das pricing-Modell basierend auf Brutto-Volumen als auch für das pricing-Modell mit hohen, nicht ausgeschöpftem Kontingent des Kunden.

Wenn denn jetzt 70% Traffic eingespart wid, ist das
ja wirklich prima für die Kunden, aber dem provider
entgehen 70% der Einnahmen aus der Weiterverkauf der
Bandbreite. Das sind rein wirtschaftliche
Interessen.

Du legst das falsche pricing-Modell zugrunde.
_So_ funktioniert es in der Tat nicht.

Ich weiß auch nicht ob Den pricing-System rechtlich
so einwandfrei ist, denn Du berechnest ja eigentlich
zu viel Traffic, da werden sich wohl diejenigen die
das eh so gemacht hätten beschweren, denn jetzt
haben alle DAUs denselben Vorteil.

Erstens ist alles rechtlich einwandfrei, was der Kunde unterschrieben hat und nicht sittenwidrig ist.

Zweitens wird nicht jeder DAU denselben Vorteil haben, weil die Komprimierung als Konzept für DAUs nicht einsetzbar ist. Der Kunde _muß_ die Komprimierung selbst konfigurieren - nicht der Provider.

Es werden also definitiv nicht alle Kunden auf komprimierte Auslieferung umstellen. Aber gerade deshalb wird die CPU-Last auf dem Server auch nicht explodieren können.

Wobei mir gerade einfällt, 70% war wohl übertrieben,
man muß ja sehen das ein großer Teil der Daten ja
kleine html-Dateien sind und vor allem Bilder!
Und die kann man so gut wie nicht komprimieren!

Richtig. Die angegebenen 50% sind ein geschätzter Mittelwert. Ein HTML-lastiges Angebot kann auch auf 70% oder noch mehr kommen.

jaja, aber damit entgehen ihm vermutlich einige
Kunden, die wenig Ahnung haben!

Wer zwingt den Provider, nur _ein_ Preismodell anzubieten?
Er kann seinem Kunden ja die Wahl lassen zwischen Einsatz mit mod_gzip und zugehörigem pricing-Modell für Netto-Traffic und ohne mod_gzip für Brutto-Traffic.

Ich würde als Provider mod_gzip also laden,
nicht aber einschalten, und den Kunden erklären,
wie sie via .htaccess eine ihren Wünschen
entsprechende Konfiguration schreiben können,
_um_ dadurch ihren Traffic-Preis zu reduzieren.
Genau das ist es was ich wollte, aber der Provider
meinte halt es gäbe bereits gute Lösungen
(multiview/Ausgabesteuerung), so dass dies wieder
nur einen Performance-Verlust zur Folge hätte für
nichts und wieder nichts.

Wenn Du das manuelle Umstellen sämtlicher Links in allen Deinen Seiten als gute Lösung ansiehst ... bitte sehr.

Wenn das den so geladen und _nicht_ benutzt wird,
kostet das denn dann überhaupt was?

Kaum. Ein bißchen RAM, natürlich (100 KB oder so). Sonst nichts.

Eben. Um so mehr muß der Provider aber daran
interessiert sein, daß die Daten komprimiert
ausgeliefert werden! Die Kunden zahlen ja immer
noch den Paketpreis, der Provider muß aber
weniger Bandbreite einkaufen!
ja aber wenn das alles so einfach wäre, warum macht
das keiner? Ich denke Du hast das Problem genannt,
das sollte Sache der Kunden sein, und welcher Kunde
der unter dem Limit bleibt schert sich um sowas?

Derjenige, der seine Besucher mit schnellen Seiten bedienen will. Derjenige, dem seine Besucher nicht egal sind. Derjenige, der selbst den Apache konfiguriert, um "Expires:"- und "Cache-Control:"-Header zu senden. Derjenige, der das Gehirn eingeschaltet hat.

Zugegeben - viele sind das nicht. ;-)

Aber gerade die Kunden, die unter dem Limit bleiben, sind es, an denen der Provider (!) sparen kann.
Denen sollte er also sagen, daß sie ihre Seiten schneller ausliefern können, ohne daß sie dafür _zusätzlich_ bezahlen müssen.
Sie bekommen mehr Service ohne Aufpreis - er muß weniger Traffic einkaufen. Beide sind glücklich.

Es hängt von der Verteilung der Seitenzugriffe
ab, ob das nicht in der Summe sogar zu einer
_Entlastung_ des Servers führt.
Meinst Du wirklich? Das senden kostet doch nun
wirklich nicht viel, komprimieren ist doch ganz was
anderes,

Beides kostet etwas.
Und der TCP/IP-Stack eines Webservers _ist_ ein potentieller Engpaß. Jedes Kilobyte, welches da nicht hindurch muß, entlastet die CPU.

oder komprimiert mod_gzip nicht immer _alles_ zur
Laufzeit? Gibt es da auch einen cache?

Ja - inzwischen kann man das so nennen.

Aber das funktiniert wieder schlecht mit dynamischen
Seiten.

Es funktioniert überhaupt nicht mit dynamischen Seiten.

Aber bei denen könntest auch Du nur zur Laufzeit jedesmal komprimieren - und _das_ kann mod_gzip eben effizienter als Du.

Das ist aber nicht der Fall - die komprimierten
Seiten können gecached werden (wahlweise in einem

Aber das macht mod_gezip doch nicht alleine, oder?

Doch, das macht mod_gzip alleine (bei statischen Dokumenten). RTFM.

Bei dynamischen geht Caching nur, wenn das Konzept der dynamischen Erzeugung des Dokuments _will_, daß das Dokument gecached werden _darf_.
Das ist also eine Entscheidung, die für jedes Dokument einzeln gefällt werden muß - in Form von HTTP-Headern, welche die entsprechende Anwendung selbst generiert.

Viele Grüße
      Michael

[Sönke Tesch]

Und wenn ich mich nicht irre, wurde obendrein zumindest in früheren PHP-Anleitungen vor der Benutzung von ob_gzhandler explizit gewarnt, weil das Ding alles andere als zuverlässig funktionierte. Deshalb besser zlib.out_compression.

wo denn?

"wurde [..] in früheren PHP-Anleitungen"

Gruß,
  soenk.e

[Andreas Korthaus]

Hi!

Und wenn ich mich nicht irre, wurde obendrein zumindest in früheren PHP-Anleitungen vor der Benutzung von ob_gzhandler explizit gewarnt, weil das Ding alles andere als zuverlässig funktionierte. Deshalb besser zlib.out_compression.

wo denn?

"wurde [..] in früheren PHP-Anleitungen"

Wenn denn heute nichts mehr da steht, sollt eman es doch ohne Probleme verwenden können, oder? Ich kenne einige Leute die das ohne Probleme einsetzen! Wäre nur dumm wenn die das alle nicht mit bestimmten Browser getestet haben ;-)

Grüße
Andreas

[Sönke Tesch]

Und wenn ich mich nicht irre, wurde obendrein zumindest in früheren PHP-Anleitungen vor der Benutzung von ob_gzhandler explizit gewarnt, weil das Ding alles andere als zuverlässig funktionierte. Deshalb besser zlib.out_compression.

Wenn denn heute nichts mehr da steht, sollt eman es doch ohne Probleme verwenden können, oder? Ich kenne einige Leute die das ohne Probleme einsetzen!

Und ich kenne einige Leute, die noch PHP 4.0 einsetzen (müssen). Ohne Kenntnis der hier verwendeten Version und des Zeitpunkts, an dem der Fehler beseitigt wurde, hat dieser Tipp IMHO etwas von russischem Roulette.

Gruß,
  soenk.e

[Sven Rautenberg]

Moin!

Puretec hat zumindest Multiviews aktiviert, also kannst du eine gewisse Krücke einbauen:

Muss ich in meine HTML-Seiten irgenwas reinschreiben ?

Wenn du alle deine HTML-Seiten zusätzlich als .gz-Datei auf den Server packst, kostet dich das zwar zusätzlichen Speicherplatz, aber der Server wählt automatisch die gezippte Version, wenn der Browser es kann - allerdings ist es in diesem Fall sinnvoll, wenn du deine Links änderst:
Der Link soll nur noch auf z.B. "index" führen, nicht mehr auf "index.html". Lege dann die zwei Dateien "index.html" und "index.html.gz" in das Verzeichnis - der Server wird eine der beiden Dateien ausliefern.

Was muss ich in meine PHP-Seiten reinschreiben ?

PHP kannst du auf diese Weise nicht komprimieren. Aber du kannst innerhalb von PHP die Ausgabe in einem Puffer abfangen und diesen vor Auslieferung komprimieren, wenn der Browser es versteht.

Ich hab' spontan das hier gefunden: http://www.phpbuilder.com/mail/php-general/2000062/0671.php

- Sven Rautenberg

[Michael Schröpl]

Hallo Sven,

Puretec hat zumindest Multiviews aktiviert,
also kannst du eine gewisse Krücke einbauen:
Wenn du alle deine HTML-Seiten zusätzlich als
.gz-Datei auf den Server packst, kostet dich das
zwar zusätzlichen Speicherplatz, aber der Server
wählt automatisch die gezippte Version, wenn der
Browser es kann

für genau dieses Szenario ist gzip_cnc gedacht, welches dem Anwender insbesondere das Ändern der Link ersparen würde.

Viele Grüße
      Michael

[Sven Rautenberg]

Moin, Michael!

Puretec hat zumindest Multiviews aktiviert,
also kannst du eine gewisse Krücke einbauen:
Wenn du alle deine HTML-Seiten zusätzlich als
.gz-Datei auf den Server packst, kostet dich das
zwar zusätzlichen Speicherplatz, aber der Server
wählt automatisch die gezippte Version, wenn der
Browser es kann

für genau dieses Szenario ist gzip_cnc gedacht, welches dem Anwender insbesondere das Ändern der Link ersparen würde.

Bei Servern ohne die Möglichkeit, irgendwelche aktiven Komponenten einzusetzen, hilft das auch nicht viel weiter. Und bei Puretec sind die kleinen Pakete leider alle nur ohne CGI zu haben. Da muss man dann manuell ran.

- Sven Rautenberg

[Pit]

index.html.gz

Irgendwie klappt die Komprimierung mit meinem UltimateZip 2.6 nicht so, ich sehe nach dem Aufruf im Browser leider ;-( nur eine leere Seite.

Wie komprimiert ihr .gz unter WIN, bzw. mit welchen Tool unter WIN ?

Pit

[Michael Schröpl]

Hi Pit,

Wie kann ich rausfinden, ob der Apache bei Purectec
so was kann, habe ja keinen Zugriff auf das Teil,
und auch in deren Doku finde ich nichts, was mir
weiterhilft ?

sende mal eine Anforderung mit
  http://www.schroepl.net/cgi-bin/http_trace.pl
zu einer solchen Seite.

Viele Grüße
      Michael