PDA

Bekijk Volledige Versie : mod_gzip - http compressie



Domenico
05/08/02, 21:12
Is er eigenlijk nog iemand die geen gebruik maakt van mod_gzip ?

Wij gebruiken het al tijden en het werkt uitstekend en kunnen alleen maar positief zijn over mod_gzip.

Het komt het erop neer dat HTML (en andere) files al dan niet on-the-fly door de server worden gecomprimeerd en vervolgens naar de client worden gestuurd, die ze vervolgens decomprimeert. Hiertoe werd werd in de HTTP1.1 specificatie de mogelijkheid voor 'content-encoding' opgenomen. Alle moderne browsers ondersteunen HTTP1.1 met content-encoding. Netscape doet dit vanaf versie 4.5 en IE vanaf versie 4.

Voor meer info kun je kijken op http://www.remotecommunications.com/apache/mod_gzip/ en http://webreference.com/internet/software/servers/http/compression/

Als je wil testen of mod_gzip is geinstalleerd op je server kun je dat hier checken -> http://leknor.com/code/gziped.php

Als er iemand een negatieve ervaring heeft met mod_gzip dan lezen we dat graag hier terug natuurlijk.

uFx
06/08/02, 00:14
Ik vraag me af of dit juist niet voor bepaalde pagina's vertraagd? Vooral voor kleinere pagina's lijkt me gzippen niet echt een goede keus.

En hoe zit het met de serverload? Merk je daar wat van of valt dat eigenlijk wel mee?

Domenico
06/08/02, 00:54
De serverload gaat wel iets omhoog aangezien er on-the-fly gezipped wordt maar niet erg veel en met de computer power van tegenwoordig maakt het al helemaal niets meer uit.

Niet alleen de ISP maar ook de bezoekers hebben er baat bij. Zeker bij de bezoekers dienog op 56k zitten zien opeens de pagina's sneller verschijnen.

Ik kan me overigens ook voorstellen dat sommige ISP's liever hebben dat er meer bandbreedte verbruikt wordt zodat ze het weer kunnen verekenen aan de klant. :)

HGM
06/08/02, 11:12
Ik vraag me af wat nu daadwerkelijk je vraag is? Of hosters nu default gzip hebben aanstaan? Indien dat de vraag is, lijkt me maar één antwoord mogelijk: Nee.

Wie is de hoster om die keuze te maken voor de klant?? Daarnaast zijn er ook nog wel een aantal situaties waarin gzip absoluut niet goed werkt en dus ook uitgezet moet kunnen worden.

Domenico
06/08/02, 11:46
Origineel geplaatst door HGM
Ik vraag me af wat nu daadwerkelijk je vraag is? Of hosters nu default gzip hebben aanstaan? Indien dat de vraag is, lijkt me maar één antwoord mogelijk: Nee.

Wie is de hoster om die keuze te maken voor de klant?? Daarnaast zijn er ook nog wel een aantal situaties waarin gzip absoluut niet goed werkt en dus ook uitgezet moet kunnen worden.

Ok, misschien dat je me kunt vertellen in welke situatie de klant er geen baat bij zou hebben dan? De verhouding is in dit geval zeker geen 50/50.

Het is zeker zo dat mod_gzip in sommige gevallen beter uitgezet kan worden maar ik denk dat het in de meeste standaard gevallen beter aan kan staan.

Heb jij slechte ervaringen met mod_gzip?

HGM
06/08/02, 11:52
Het is toch de keuze van de klant om hier wel/niet gebruik van te maken?
Vraag me ook af hoe je het aangezet hebt: altijd of als de browser ermee om kan gaaan?

Iig met inline PDF files ed gaat het vaak volledig mis.


Het is zeker zo dat mod_gzip in sommige gevallen beter uitgezet kan worden maar ik denk dat het in de meeste standaard gevallen beter aan kan staan.En hoe kunnen jullie klanten dit dan voor elkaar krijgen?

IMO is het gewoon de taak van de provider niet, de provider moet ervoor zorgen dat alles werkt en dat deze (ea) opties mogelijk zijn. De klant kiest ervoor om het wel/niet te gebruiken.

Domenico
06/08/02, 12:00
Mod_gzip is een keuze die de ISP maakt. De klant kan het volgens mij compleet uitschakelen door in bijv. explorer de optie http 1.1 uit te zetten maar ik heb eigenlijk nooit problemen gehad met mod_gzip en ook hebben er nog nooit klanten geklaagd.

Als de browser het niet aan kan wordt er helemaal niets gecomprimeerd en gaat de transfer standaard verder.

Maar nogmaals, waarom zou een klant er geen gebruik van willen maken?

Deimos
06/08/02, 12:17
Heb slechte ervaring met mod_gzip. Naar mijn idee scheelt de compressie helemaal geen dataverkeer (in ieder geval geen merkbare hoeveelheid). En verder zelf enorm veel gedonder gehad dat mijn on the fly gegenereerde PDF's niet werkten aangezien mod gzip aanstond.

uFx
06/08/02, 12:24
Ik heb zo'n gevoel dat mod_gzip juist meer tijd met zich meebrengt. Ik geloof dat mensen met een 14k4 modem hier baat bij hebben, maar dat juist mensen met een snellere verbinding benadeeld worden:

- Pagina wordt opgevraagd;
- Server kijkt ofdat gzip mogelijk is; *
- Indien niet mogelijk, standaard doorsturen, anders inpakken; *
- Pagina wordt verstuurd;
- Wordt aan de andere kant weer uitgepakt. *

Dan zijn 3 extra stappen (*), dus 3 extra processen per http request. Lijkt me nogal vertragend werken ;)

Domenico
06/08/02, 13:01
Bij bijvoorbeeld tweakers staat hij gewoon aan :)

HGM
06/08/02, 13:18
Origineel geplaatst door Domenico
Bij bijvoorbeeld tweakers staat hij gewoon aan :)
Niet gewoon hoor, daar wordt actief gekeken of de bezoeker de mogelijkheid heeft. Op het forum kan je zelf aangeven: "Gebruik http-compressie?".

Daarbij wil je toch T.net niet gaan vergelijken met een hostingsbedrijf, waar tig klanten op één server zitten :o

Domenico
06/08/02, 13:26
Als je het principe van mod_gzip zou begrijpen dan zou je moeten weten dat als de browser geen compressie ondersteunt de data uncompressed wordt verstuurd.

Ik noemde tweakers gewoon als voorbeeld van een drukke site en anders moet je maar lezen wat femme taken er zelf over schrijft op de site.

Anyways, ik heb nog steeds geen goed argument gehoord waarom je het persee NIET moet gebruiken.
Verder wil ik niet verder gaan met deze welles/nietes discussie dus aub even alleen maar argumenten van waarom wel en waarom niet als het kan.

HGM, het is duidelijk dat jij geen voorstander bent en dat is ok maar vertel ons dan waarom deze aversie.

HGM
06/08/02, 13:56
Origineel geplaatst door Domenico
[B]Als je het princiepe van mod_gzip zou begrijpen dan zou je moeten weten dat als de browser geen compressie ondersteunt de data uncompressed wordt verstuurd.En waaruit maak je op dat ik dat niet begrijp?? Daarnaast werkt dat dus niet in alle gevallen ok.



Ik noemde tweakers gewoon als voorbeeld van een drukke site en anders moet je maar lezen wat femme taken er zelf over schrijft op de site.ALs je dat dan even zou onderbouwen met een linkje ofzo ;) Daarnaast zie ik mod_gzip pas op 31 juli van dit jaar verschijnen: uptime.netcraft (http://uptime.netcraft.com/up/graph?site=tweakers.net)


Anyways, ik heb nog steeds geen goed argument gehoord waarom je het persee NIET moet gebruiken.
Verder wil ik niet verder gaan met deze welles/nietes discussie dus aub even alleen maar argumenten van waarom wel en waarom niet als het kan.
Tja, er zijn wel een paar argumenten genoemd, dat jij ze niet goed vind is wat anders. In noem, inline (dynamische) pdf-files, geen verantwoordelijkheid vd provider maar van de klant, met proxy-gebruik gaat het ook regelmatig mis.

Daarnaast stel je:

De klant kan het volgens mij compleet uitschakelen door in bijv. explorer de optie http 1.1 uit te zetten ... Dan heeft de klant het toch niet uitgezet, maar de bezoeker :?

Domenico
06/08/02, 14:11
Met dat laatste bedoelde ik dus de bezoeker :)
De link van het artikel --> http://www.tweakers.net/plan/56
Netcraft? Is niet zo betrouwbaar als je denkt hoor.
En wat werkt wel 100% op je computer en op het internet?

Je belangrijkste argument is dus dat je vindt dat de klant de optie moet hebben om te kiezen tussen wel en geen mod_gzip? Dat kan toch door een hoster te kiezen die het wel of niet heeft geinstalleerd...

Naja, we zullen elkaar wel niet erg goed begrijpen vandaag maar no hard feelings offcourse ;)

HGM
06/08/02, 14:22
Origineel geplaatst door Domenico
De link van het artikel --> http://www.tweakers.net/plan/56
Dat is dus actief dmv php-scripting en geen mod_gzip onder Apache hoor. En om nu je hele verhaal te onderbouwen met een documentje uit het jaar 2000 lijkt me een beetje onzinnig.


Netcraft? Is niet zo betrouwbaar als je denkt hoor. In dit geval wel IMO en wederom waar is de onderbouwing?


En wat werkt wel 100% op je computer en op het internet? Dit slaat dus helemaal nergens op. Iig als ik iets wil gebruiken moet het perfect werken anders maak ik er liever een optie van.



Naja, we zullen elkaar wel niet erg goed begrijpen vandaag maar no hard feelings offcourse ;) Ik begrijp het heel goed hoor.

Deimos
06/08/02, 14:25
Je belangrijkste argument is dus dat je vindt dat de klant de optie moet hebben om te kiezen tussen wel en geen mod_gzip? Dat kan toch door een hoster te kiezen die het wel of niet heeft geinstalleerd...

Dat je stelt dat de klant zelf keuze heeft door een hoster te kiezen in een onzin argrument, dat zou jij als hoster zijnde toch moeten weten. Je kan moeilijk eisen dat al je klanten het gaan gebruiken. Want dan werken bepaalde scripts niet meer en wat gebeurd er dan ontevreden klanten. En wie heeft daar baat bij? Geen van beide partijen dus waarom aanzetten zodat jij wellicht 1 Gb per maand minder dataverkeer verbruikt? Want IMO is dat de gedachte achter het geheel zelf minder kosten maken en echt niet de klantssite verbeteren.

Domenico
06/08/02, 14:36
T.net artikel was niet om heel het verhaal te onderbouwen maar meer een verhaal over de voordelen van html compressie en dus niet hoe.
Ik lees op het net meer voordelen dan nadelen maar misschien dat je me wat sites kunt laten zien waar er uitgebreid wordt gepraat over de nadelen van html compressie.

Netcraft, ik kan mod_gzip installed hebben terwijl netcraft het niet kan zien en andersom en met meerdere modules.

Slaat nergens op? Welke webservers draai jij? Apache? IIS? Werken deze altijd perfect? Maar heeft inderdaad niets met deze discussie te maken.

Ik heb al eerder gezegd dat er voordelen en nadelen zijn dus je hoeft me niet te overtuigen dat er nadelen kunnen zijn want dat weet ik al.
Ik ben gewoon benieuwd naar eigen ervaringen van anderen.

Domenico
06/08/02, 14:45
Origineel geplaatst door Deimos

Dat je stelt dat de klant zelf keuze heeft door een hoster te kiezen in een onzin argrument, dat zou jij als hoster zijnde toch moeten weten. Je kan moeilijk eisen dat al je klanten het gaan gebruiken. Want dan werken bepaalde scripts niet meer en wat gebeurd er dan ontevreden klanten. En wie heeft daar baat bij? Geen van beide partijen dus waarom aanzetten zodat jij wellicht 1 Gb per maand minder dataverkeer verbruikt? Want IMO is dat de gedachte achter het geheel zelf minder kosten maken en echt niet de klantssite verbeteren.

Deimos, heb zelf geen ervaring met scripts die niet werken met mod_gzip en heb het ook nergens kunnen vinden dus als je me kunt informeren hierover graag.

De extra dataverkeer die wordt verbruikt wordt gewoon afgerekend door de klant dus ik weet niet wat hiervan het voordeel/nadeel zou kunnen zijn voor de ISP. Er is genoeg bandbreedte aanwezig en je kunt het zo bijkopen zoals we allemaal weten.
Denk je echt dat dit het enige voordeel kan zijn voor een ISP?
Wat vindt je van de uitleg op de links die ik heb gegeven in de eerste post? Allemaal onzin?

Ok, nieuwe stelling:
Mod_gzip (en andere vormen van datacompressie) is achterhaald en heeft totaal geen bestaansrecht meer.

Is dit de gedachte?

Deimos
06/08/02, 15:00
Origineel geplaatst door Domenico


Deimos, heb zelf geen ervaring met scripts die niet werken met mod_gzip en heb het ook nergens kunnen vinden dus als je me kunt informeren hierover graag.

Als ik en HGM zeggen dat bepaalde script dan niet werken en we noemen een voorbeeld (inline PDF). En jij zegt dat je niets kunt vinden vraag ik me toch af of je het niet hebt gelezen of het niet wilt lezen.



De extra dataverkeer die wordt verbruikt wordt gewoon afgerekend door de klant dus ik weet niet wat hiervan het voordeel/nadeel zou kunnen zijn voor de ISP. Er is genoeg bandbreedte aanwezig en je kunt het zo bijkopen zoals we allemaal weten.
Denk je echt dat dit het enige voordeel kan zijn voor een ISP?

Bij een server zit standaard een x gieg dataverkeer. Dat dataverkeer is relatief gezien goedkoop tegenover de prijs voor extra dataverkeer. Stel ik kom nu boven die standaard x gieg uit. Moet ik bijkopen is duurder. Met gzip bespaar je dataverkeer. En als ik eerlijk ben geloof ik niet dat jij niet "overselled".


Wat vindt je van de uitleg op de links die ik heb gegeven in de eerste post? Allemaal onzin?

Ik zeg niet dat het onzin is, dat maak jij dervan. Ik zeg, dat ik netzoals HGM vind dat jij niet de keuze mag maken voor de klant want zoiets doe je nu.

Ok, nieuwe stelling:
Mod_gzip (en andere vormen van datacompressie) is achterhaald en heeft totaal geen bestaansrecht meer.

Is dit de gedachte?
Dit is helemaal verkeerde conclusie datacompressie heeft idd voordelen, maar je mag en kan niet voor tig klanten bepalen van: ZO en voortaan werken we met mod gzip en als je dat niet wilt ga je maar naar een ander. Want daar komt het dan eigenlijk opneer, aangezien je (voor zover ik weet) mod_gzip niet per virtualhost kan in/uitschakelen.

En als de klant zelf compressie wilt gebruiken, dan hebben ze altijd de keuze om php scripts of andere compressie scripts te gebruiken. En dan heeft de klant dus wel zelf de keuze en wordt deze niet opgelegt door iemand die denkt van: He! Dat mod_gzip lijkt me wel wat eens testen.,

Domenico
06/08/02, 15:12
Kom op Deimos, ik zeg niet we hebben mod_gzip installed en als je er niet mee eens bent dan moet je maar naar een ander want dat slaat idd nergens op en ik ben ook niet iemand die denkt van he dat lijkt me wel wat laten we het eens testen ten koste van alle klanten :(

Er worden in deze thread wat overhaaste conclusies getrokken wat kan duiden op het langs elkaar heen lullen en dat is niet de bedoeling.

Laten we dus gewoon ophouden met de negatieve kant van deze thread en ons weer richten op de module zelf en/of andere mogelijkheden van compressie zoals de mogelijkheid om het individueel te regelen mbv PHP.

Maar wat als je geen PHP gebruikt? Zijn hier nog andere mogelijkheden voor?

ps. geloof het of niet maar wij zijn niet aan het 'oversellen' en er is bandbreedte genoeg :)

ps2. leg je als hoster niet altijd een bepaalde gedachte op aan je klanten? Het is de hoster die kiest welke configuraties en software er wordt gebruikt en het is de klant die gaat rondkijken en daarna besluit wat bij hem past.

superior-is
06/08/02, 15:35
Maar goed dat het een stuk koeler in het land is. :)

Mijn menig over het mod_zip is dat het voor een shared hosting omgeving niet zo bar veel uitmaakt. We praten in het gunstige geval over een 10% compressie over het geheel en dus 10% minder dataverkeer. Vooral in een shared hosting omgeving kan het juist nadelig uitpakken ipv positief. Je server moet presteren voor het compressen van huis-tuin en keuken sites welke vnl. veel plaatjes gebruiken ipv tekst.

Kijk host je van die .gov/.edu/.org sites -- en dan moet je denken aan die ellelange html pagina's waar menig mens een gespierde middelvinger krijgt door het scrollen -- dan scheelt het enorm. Host je voornamelijk mkb sites dan is de server waarschijnlijk drukker bezig om de zooi te compressen. Die tijd kan hij beter gebruiken om meer mensen te 'serven'.

Volgens mij was tweakers.net ook een tijd van het mod_zip afgestapt omdat de servers het juist enorm zwaar krijgen terwijl qua compressie niet echt spannende resultaten werden geboekt. Misschien doordat ze nu in een load-balanced geheel zitten ze de boel weer willen oppikken.

Deimos
07/08/02, 03:11
Ben me toch wat in mod_gzip gaan verdiepen en je kan de compressie ook aan / uit zetten per virtualhost. Momenteel ga ik het dus geheel testen voor een persoonlijke site, ik zal de resultaten wel posten.

Mike
08/08/02, 23:43
Hmm, of de processor echt zwaarder belast wordt valt te betwijfelen. Tuurlijk, gzippen kost wat extra paardenkracht, maar het gevolg is een kleinere hoeveelheid data die sneller verstuurd is waardoor de processor eerder tijd heeft voor de volgende opdracht.

Wat weegt nu zwaarder? ;)

superior-is
09/08/02, 17:41
Dat moet je dus afwegen. :D