[PHP] Aan te raden om pagina te gzippen?

[Verwijderd]

Ik kwam het volgende script tegen op dit forum, namelijk een gzip script: [rml]Zef in "[ codebase] post hier je zinnige code!"[/rml]

Nu is mijn vraag; heeft dit werkelijk zoveel effect dat het aan te raden is om te doen? En hoe wordt dit ondersteund door de browsers en dergelijke? (Ik las dat er problemen waren met Konqueror/Lynx...)

Alvast bedankt.

[eborn]

Zover ik weet zit dit ook al standaard als functie in PHP ingebouwd. Het werkt over het algemeen gewoon goed bij de standaard browsers. Op andere browsers kan het inderdaad problemen opleveren omdat ze het niet ondersteunen, maar hier heb ik geen ervaringen mee. Overigens geeft het wel een extra belasting op je systeem. Simpel gezegd wissel je dus bandbreedte in voor CPU power.

[Soultaker]

Zoals in Zef's code ook al te zien is, kun je gewoon in de HTTP headers zien of de client deflated data accepteert. Zoniet, dan stuur je natuurlijk gewone tekst. In veel gevallen zal je dus wel gewoon deflated data kunnen versturen. Het gaat dus eigenlijk nooit fout.

Of het aan te raden is, hangt af van de relatieve kosten van bandbreedte en processorkracht. Met deflate bespaar je zo'n 70% op de grootte van je document en wat minder (maar waarschijnlijk nog steeds wel 50%?) op daadwerlijke bandbreedte, maar dan moet je dus ook al je content (plaatjes en dergelijke) gecomprimeerd oversturen (anders is het effect natuurlijk veel beperkter). Wat de performance overhead precies is (ten op zichte van een gewone PHP pagina) weet ik niet exact; ik kan me voorstellen dat het meevalt voor een beetje ingewikkelde pagina (het deflate algoritme is vrij efficient en goed geoptimaliseerd).

[dawuss]

Over het algemeen is een processor een éénmalige investering, voor bandbreedte betaal je per GB, dus als het daadwerkelijk 50% scheelt...

.GIF, .JPG, en .PNG zijn helaas niet echt te GZippen, en dat zijn nou juist de bandbreedtevreters.

[sjokki]

Er zit een bug in bepaalde versies van internet explorer. Zie http://www.schroepl.net/projekte/mod_gzip/browser.htm

Die bug zorgt ervoor dat de eerste 2KB van een pagina verdwijnt. Als symptoom heeft het dat mensen klagen dat ze de pagina soms zonder opmaak (stylesheet) krijgen.

Die mensen kunnen het oplossen door de servicepacks te installeren, wat zowiezo niet onverstandig is.

[eborn]

dawuss schreef op 06 augustus 2003 @ 19:14:
.GIF, .JPG, en .PNG zijn helaas niet echt te GZippen, en dat zijn nou juist de bandbreedtevreters.

Worden afbeeldingen sowieso niet vaker gecached?

[Verwijderd]

Hmmm, ik denk dat ik beter kan gaan kijken naar cache-mogelijkheden...

[Spider.007]

Verwijderd schreef op 06 August 2003 @ 22:44:
Hmmm, ik denk dat ik beter kan gaan kijken naar cache-mogelijkheden...

Nou... en dat is me toch een rotzooi Ik ben al redelijke tijd bezig geweest; maar ik krijg het niet voor elkaar om Apache fatsoenlijke 304 headers te laten versturen voor images.... Maargoed.. mocht je een goed voorbeeld tegen komen

[bigtree]

Spider.007 schreef op 06 August 2003 @ 23:11:
[...]


Nou... en dat is me toch een rotzooi Ik ben al redelijke tijd bezig geweest; maar ik krijg het niet voor elkaar om Apache fatsoenlijke 304 headers te laten versturen voor images.... Maargoed.. mocht je een goed voorbeeld tegen komen

Apache doet dat fantastisch... by default! Misschien niet een probleem aan de client-kant?

Of genereer je soms dynamische plaatjes? Op de disk cachen + redirecten en Apache doet de rest.

[Spider.007]

bigtree schreef op 06 August 2003 @ 23:30:
[...]
Apache doet dat fantastisch... by default! Misschien niet een probleem aan de client-kant?

Of genereer je soms dynamische plaatjes? Op de disk cachen + redirecten en Apache doet de rest.

Het gaat hier om plaatjes die door een PHP script worden verstuurd....


_{Ja ik ben wat laat met reageren ja}

[bigtree]

Spider.007 schreef op 07 augustus 2003 @ 23:05:
[...]
Het gaat hier om plaatjes die door een PHP script worden verstuurd....

Dan is het de vraag hoe dynamisch die plaatjes zijn. Als die bij elke request veranderen heeft cachen geen zin.

Als het bijvoorbeeld thumbnails van foto's zijn, dan heeft het wel degelijk zin om die op de disk te cachen. Gewoon als .jpg opslaan en daar naar verwijzen vanuit je html-pagina, eventueel via een php-script dat checkt of de thumbnail moet worden bijgewerkt en weer doorstuurt naar de fysieke thumbnail-jpg. Apache regelt die 304 headers dan wel voor je.

[maartenvdv737]

Als ik het goed heb worden gecachede bestanden pas opnieuw gedownload als de datum is veranderd. Dynamisch gegenereerde plaatjes kunnen dus niet gecached worden. Je zal ze als .jpg moeten opslaan, net wat Bigtree al zegt.

Wij doen dat ook zo en dat werkt prima. We hebben in totaal 300000 foto's op die manier opgeslagen en het filesystem vindt het wel prima.

Verder gebruiken wij ook Gzip, met mod_gzip als apache module. Dit werkt zeker heel goed!! Voor html output alleen natuurlijk. Die bug in internet explorer bestaat welliswaar, maar wij hebben er nooit grote hinder van ondervonden.