Onderwerp: [Apache] Web traffic comprimeren met mod_gzip

Zomaar een tip waar ik zelf vandaag pas achter kwam: je kunt de output van
Apache transparant laten comprimeren door mod_gzip, zodat je site sneller
laadt (aannemende dat netwerk I/O de bottleneck is, niet server CPU) en je
minder dataverkeer consumeert. HTML wordt bij mij tot 19% teruggebracht.

De CPU-overhead lijkt heel aanvaardbaar te zijn. Aangezien het op een
Accept-Encoding header van de browser gebaseerd is, zou het geen browser-
en spider-problemen moeten veroorzaken.

Zie: http://sourceforge.net/projects/mod-gzip/

Ik heb zelf Debian Linux 3.0 (woody):
apt-get install libapache-mod-gzip
.... en de installatie-instructies in
http://groups.google.nl/groups?hl=nl...ayonline.id.au
volgen.

Testen kan op http://leknor.com/code/gziped.php

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman schreef:
> Zomaar een tip waar ik zelf vandaag pas achter kwam: je kunt de output van
> Apache transparant laten comprimeren door mod_gzip, zodat je site sneller
> laadt (aannemende dat netwerk I/O de bottleneck is, niet server CPU) en je
> minder dataverkeer consumeert. HTML wordt bij mij tot 19% teruggebracht.
>
> De CPU-overhead lijkt heel aanvaardbaar te zijn. Aangezien het op een
> Accept-Encoding header van de browser gebaseerd is, zou het geen browser-
> en spider-problemen moeten veroorzaken.

Alleen IE6 heeft een bug: ge-mod_gzip-te bestanden worden niet
door de browser gecached. Voor html-bestanden valt daar doorgaans mee te
leven, maar bij (terugkerende) afbeeldingen is het vervelend.

Workaround, in httpd.conf:

<FilesMatch "\.(gif|jpg|png)$">
mod_gzip_on No
</FilesMatch>


--
groet, Ronald

Ronald Klip schreef:
>
> Alleen IE6 heeft een bug: ge-mod_gzip-te bestanden worden niet
> door de browser gecached.

Correctie: alleen afbeeldingen worden niet gecached.

--
groet, Ronald

Ronald Klip schreef:
> Alleen IE6 heeft een bug: ge-mod_gzip-te bestanden worden niet
> door de browser gecached. Voor html-bestanden valt daar doorgaans mee te
> leven, maar bij (terugkerende) afbeeldingen is het vervelend.
>
> Workaround, in httpd.conf:
>
> <FilesMatch "\.(gif|jpg|png)$">
> mod_gzip_on No
> </FilesMatch>

Je kan je afvragen of mod_gzip voor (gecomprimeerde) afbeeldingen zoveel
zin heeft: je zal die afbeeldingen toch niet veel kleiner kunnen krijgen.

Maw: bovenstaande kan helemaal geen kwaad.

Aan de andere kant: kan je bij afbeeldingen ook geen cache-informatie
toevoegen (iets als de HTML Cache-headers)?

Mvg,
Robrecht

Ronald Klip:
>Ronald Klip:
>> Alleen IE6 heeft een bug: ge-mod_gzip-te bestanden worden niet
>> door de browser gecached.
>
>Correctie: alleen afbeeldingen worden niet gecached.

OK, maar volgens de configuratie in de installatie-instructies die ik
linkte worden afbeeldingen niet gecomprimeerd. Normaliter zijn die al goed
gecomprimeerd en heeft dat geen zin.

..js en .css worden volgens die config trouwens ook niet gezipped. Zouden
daar ook zulke problemen mee zijn?

Hier wordt i.i.g. melding gemaakt van een bug in de oude Netscape-browser
met gecomprimeerde css:
http://www.webmasterworld.com/forum83/547.htm
En ook "Make sure you don't try mod_gzip on standalone Javascript code,
either".

Grrr.. wanneer zou software toch eens volwassen worden?

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Robrecht Jacques schreef:
> Ronald Klip schreef:
> >
> > Workaround, in httpd.conf:
> >
> > <FilesMatch "\.(gif|jpg|png)$">
> > mod_gzip_on No
> > </FilesMatch>
>
> Je kan je afvragen of mod_gzip voor (gecomprimeerde) afbeeldingen zoveel
> zin heeft: je zal die afbeeldingen toch niet veel kleiner kunnen krijgen.

Inderdaad; meestal worden plaatjes al uitgesloten van compressie met
mod_gzip_item_exclude mime ^image/.*
Desondanks wil IE6 ze niet cachen.

> Maw: bovenstaande kan helemaal geen kwaad.
>
> Aan de andere kant: kan je bij afbeeldingen ook geen cache-informatie
> toevoegen (iets als de HTML Cache-headers)?

Ja, dat zou kunnen, maar lijkt me wat omslachtig. Bovendien kosten
headers ook bandbreedte, en daar was 't 'm juist om te doen.

--
groet, Ronald

Ronald Klip schreef:
> Robrecht Jacques schreef:
>>Ronald Klip schreef:

>>Aan de andere kant: kan je bij afbeeldingen ook geen cache-informatie
>>toevoegen (iets als de HTML Cache-headers)?
>
> Ja, dat zou kunnen, maar lijkt me wat omslachtig. Bovendien kosten
> headers ook bandbreedte, en daar was 't 'm juist om te doen.

Boah. Als je éénmaal een header moet meesturen en daarmee X extra
downloads van je beeldjes uitspaart, dan is dat zo erg niet. Tenzij
natuurlijk IE _nooit_ beeldjes cachet (wat me zou verbazen trouwens).

Mvg,
Robrecht

> De CPU-overhead lijkt heel aanvaardbaar te zijn. Aangezien het op een
> Accept-Encoding header van de browser gebaseerd is, zou het geen browser-
> en spider-problemen moeten veroorzaken.
>
> Zie: http://sourceforge.net/projects/mod-gzip/

En er komt een dag dat je ook de CPU load wil verlagen en dan denk je aan
mod_proxy, mod_proxy is not a proxy, lol. Dan cache je PHP output, zoals bv
content.php die uit je database cms de tekst haalt. Die hoeft niet elke keer
opnieuw de database te lezen, doet ie dat eens per 5 minuten dan is het ook
ok.

Ik host bv www.forza-utreg.nl (supporters website voor de beste club van
Nederland ;-)) en daar komen veel bezoekers op en dan scheelt het veel load.
Hoewel HTML idd flink te zippen is is HTML toch altijd redelijk klein tov
andere bestanden (flash, images, java).

Beter zou zijn als ze HTML/websites gaan compileren naar tokenised HTML (dus
ipv een woord 1 nummer per tag) en dan met (onzichtbare) versienummers gaan
werken net als bij DNS zeg maar zodat men beter kan cachen.

En nu iedereen breedband heeft is dit ook minder actueel denk ik, dit had je
5 jaar geleden al moeten gebruiken, lol. Voor grote HTML content (online
handleidingen ed.) of mega javascript/dhtml sites icm een trage link zie ik
wel de voordelen ofcourse en ik heb het er ook altijd in geloof ik (ahum).

Rene Pijlman schreef:
> Ronald Klip:
> >Ronald Klip:
> >> Alleen IE6 heeft een bug: ge-mod_gzip-te bestanden worden niet
> >> door de browser gecached.
> >
> >Correctie: alleen afbeeldingen worden niet gecached.
>
> OK, maar volgens de configuratie in de installatie-instructies die ik
> linkte worden afbeeldingen niet gecomprimeerd. Normaliter zijn die al goed
> gecomprimeerd en heeft dat geen zin.

Nee, inderdaad, maar IE6 wil afbeeldingen desondanks niet cachen.

> .js en .css worden volgens die config trouwens ook niet gezipped. Zouden
> daar ook zulke problemen mee zijn?

Ik heb destijds ook maar klakkeloos die default-configuratie
overgenomen...
Net even een testje uitgevoerd, met dit in de .htaccess van de
directory:

mod_gzip_item_include file \.css$
mod_gzip_item_include file \.js$

Hiermee zouden externe css en js dus gezipt moeten worden.

IE6:
css wordt gezipt en gecached
js wordt niet gezipt en niet gecached
Firefox, Opera:
css wordt gezipt en gecached
js wordt niet gezipt maar wel gecached

Wellicht kan het dus geen kwaad om .css wel te laten comprimeren. Maar
erg veel zin heeft dat niet, omdat het bestand normaal gesproken toch
al gecached wordt.

> Hier wordt i.i.g. melding gemaakt van een bug in de oude Netscape-browser
> met gecomprimeerde css:
> http://www.webmasterworld.com/forum83/547.htm

Aha. Blijkbaar weer op te lossen met
mod_gzip_item_exclude reqheader "User-agent: Mozilla/4.0[678]"

> En ook "Make sure you don't try mod_gzip on standalone Javascript code,
> either".
>
> Grrr.. wanneer zou software toch eens volwassen worden?

Kweenie..

--
groet, Ronald

Robrecht Jacques schreef:
> Ronald Klip schreef:
> > Robrecht Jacques schreef:
> >>Ronald Klip schreef:
>
> >>Aan de andere kant: kan je bij afbeeldingen ook geen cache-informatie
> >>toevoegen (iets als de HTML Cache-headers)?
> >
> > Ja, dat zou kunnen, maar lijkt me wat omslachtig. Bovendien kosten
> > headers ook bandbreedte, en daar was 't 'm juist om te doen.
>
> Boah. Als je éénmaal een header moet meesturen en daarmee X extra
> downloads van je beeldjes uitspaart, dan is dat zo erg niet. Tenzij
> natuurlijk IE _nooit_ beeldjes cachet (wat me zou verbazen trouwens).

Mwa, het lijkt mij toch simpeler om gif|jpg|png uit te sluiten van
mod_gzip met genoemde instructie. Maar het is een beetje lood om oud
ijzer, en zo'n header zal geen gigabytes extra opleveren.

--
groet, Ronald

Onno wrote...

> Beter zou zijn als ze HTML/websites gaan compileren naar tokenised HTML (dus
> ipv een woord 1 nummer per tag)

Oh jee, ik denk nu opeens aan WAP... laat ik maar snel verder lezen

> en dan met (onzichtbare) versienummers gaan
> werken net als bij DNS zeg maar zodat men beter kan cachen.

Dit is er al: ETags. Maar wees gewaarschuwd: ETags en Gzippen samen
vindt IE6 niet leuk, en je zult zeker tegen bugs in IE lopen, dus test
voordat je zoiets in productie zet om te kijken of de gewenste
combinatie van headers de gewenste resultaten oplevert (bijvoorbeeld met
ieHTTPHeaders).

> En nu iedereen breedband heeft is dit ook minder actueel denk ik, dit had je
> 5 jaar geleden al moeten gebruiken, lol. Voor grote HTML content (online
> handleidingen ed.) of mega javascript/dhtml sites icm een trage link zie ik
> wel de voordelen ofcourse en ik heb het er ook altijd in geloof ik (ahum).

Ach, een 80% besparing op bandbreedte-gebruik is natuurlijk altijd leuk.
Of de gebruiker nou breedband heeft of niet. Maar het is natuurlijk wel
afhankelijk van je site: als je 10 kB aan HTML-traffic bespaart om
daarna een 1 MB bitmap plaatje als achtergrond te gebruiken schiet het
inderdaad niet zo op

David

Rene Pijlman wrote:
> Zomaar een tip waar ik zelf vandaag pas achter kwam: je kunt de output van
> Apache transparant laten comprimeren door mod_gzip, zodat je site sneller
> laadt (aannemende dat netwerk I/O de bottleneck is, niet server CPU) en je
> minder dataverkeer consumeert. HTML wordt bij mij tot 19% teruggebracht.
>
> De CPU-overhead lijkt heel aanvaardbaar te zijn. Aangezien het op een
> Accept-Encoding header van de browser gebaseerd is, zou het geen browser-
> en spider-problemen moeten veroorzaken.
>
> Zie: http://sourceforge.net/projects/mod-gzip/
>
> Ik heb zelf Debian Linux 3.0 (woody):
> apt-get install libapache-mod-gzip
> ... en de installatie-instructies in
> http://groups.google.nl/groups?hl=nl...ayonline.id.au
> volgen.
>
> Testen kan op http://leknor.com/code/gziped.php
>

Wat mij betreft de tip van de maand !

Ik host een aantal websites achter mijn adsl lijn, lekker goedkoop. Dan
komt zoiets wel van pas. Het installeren onder woody was een fluitje van
een cent. Alleen de logfile doet het niet, maar dat schijnt een bekend
probleem te zijn.

Michiel de Roo:
>Wat mij betreft de tip van de maand !

Mooi. Jammer dat die maar eens in de drie maanden komen :-)

>Ik host een aantal websites achter mijn adsl lijn, lekker goedkoop. Dan
>komt zoiets wel van pas. Het installeren onder woody was een fluitje van
>een cent. Alleen de logfile doet het niet, maar dat schijnt een bekend
>probleem te zijn.

Wie wil er nou een logfile van zijn compressiemodule? Ik kan het werkelijk
niet bedenken. Nadat ik drie regels log had gezien (hij deed het bij mij
trouwens wel) heb ik dat snel uitgezet.

Heb je die 3 regels uit de Usenet-posting die ik linkte wel goed op 1
regel gejoined?

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman wrote:
> Michiel de Roo:
>
>>Wat mij betreft de tip van de maand !
>
>
> Mooi. Jammer dat die maar eens in de drie maanden komen :-)
>
>
>>Ik host een aantal websites achter mijn adsl lijn, lekker goedkoop. Dan
>>komt zoiets wel van pas. Het installeren onder woody was een fluitje van
>>een cent. Alleen de logfile doet het niet, maar dat schijnt een bekend
>>probleem te zijn.
>
>
> Wie wil er nou een logfile van zijn compressiemodule? Ik kan het werkelijk
> niet bedenken. Nadat ik drie regels log had gezien (hij deed het bij mij
> trouwens wel) heb ik dat snel uitgezet.

;-)

>
> Heb je die 3 regels uit de Usenet-posting die ik linkte wel goed op 1
> regel gejoined?
>

Ja, dat is het niet. Ik vond wel een patch, maar ik heb geen zin om te
gaan compileren.

"Rene Pijlman" <reply.in.the.newsgroup@my.address.is.invalid> wrote in
message news:j7ljh01im4inii7dmnf9hdbjkm5oejh707@4ax.com...
> Zomaar een tip waar ik zelf vandaag pas achter kwam: je kunt de output van
> Apache transparant laten comprimeren door mod_gzip, zodat je site sneller
> laadt (aannemende dat netwerk I/O de bottleneck is, niet server CPU) en je
> minder dataverkeer consumeert. HTML wordt bij mij tot 19% teruggebracht.

Voor Apache 2 kun je gebruik maken van mod_deflate,
http://httpd.apache.org/docs-2.0/mod/mod_deflate.html, voor zover ik weet
werkt mod_gzip namelijk alleen met Apache 1.3.x ( een snelle check van de
mod_gzip site bevestigd dit).

Het wel of niet gezippen van bepaalde MIME typen kan met zowel mod_gzip als
mod_deflate ingesteld te worden daar heb je geen separate configuratie voor
nodig in httpd.conf zoals verderop in de posting aangegeven:

Dus:

<FilesMatch "\.(gif|jpg|png)$">
mod_gzip_on No
</FilesMatch>

Kun je vervangen door:

mod_gzip:
mod_gzip_item_exclude mime ^image/

mod_deflate:
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary

Voor afbeeldingen zou ik zelf trouwens mod_expires nemen om de caching
effecten van afbeeldingen onder controle te houden.

Het aardige is trouwens dat als het om echte bandbreedte besparing gaat je
wellicht meer rendement haalt uit een strakke markup van je site met keurige
verdeling van presentatie naar css en javascript bestanden, zie
http://www.stopdesign.com/articles/throwing_tables/ voor een mooi voorbeeld
hoe er 62% bestandsreductie wordt gerealiseerd op de www.microsoft.com
website.

Groetjes,

Meint