HTTP compressie test

Naar aanleiding van deze thread ('http compression - it rocks') op het forum hebben ik en Arjen gisteren wat zitten spelen met het gebruik van HTTP compressie op Athena. Het idee achter HTTP compressie wordt uitgebreid uitgelegd in dit artikel van Webreference.com. Basicly 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 met uitzondering van de Mac varianten (boeiuh )

Naast het voorpletten van statische files is het mogelijk om de resultaten van dynamische scripts on-the-fly te comprimeren. Hiervoor gebruiken we dit simpele PHP scripsel. Alles wat je nodig hebt is een met zlib gecompileerde (thanks Rick) PHP4.0.1 of hoger. Het PHP script checkt of de client zip encoding ondersteunt en stuurt afhankelijk daarvan de gecomprimeerde of ongecomprimeerde inhoud van de pagina. Voor de gebruiker is HTTP compressie, afgezien van de behoorlijke hoge snelheidswinst die je er mee kunt behalen, volledig transparant.

Mijn eerste tests met de t.net nieuwspagina's leverden al meteen erg spectaculaire resultaten op. Afhankelijk van de grootte van de pagina werd een compressie ratio tussen 1:2,5 en 1:6 behaald. Meer dan 1:5 blijkt vrij normaal te zijn voor pagina's met veel reacties. Het verschil tussen 50 en 10KB is gigantisch voor mensen die gekweld worden door een trage verbinding. Het verbaast me dan ook dat er in de praktijk nog nauwelijks gebruik wordt gemaakt van dit geniale idee .

De effecten zijn uiteraard minder merkbaar voor tweakers die al gezegend zijn met een aso dikke SURFnet of Cistron internet pijp. Het verschil kun je checken door '&nocompr=true' achter de URL van een pagina te plakken. De compressie ratio kun je in je status bar vangen door '&debug=true' toe te voegen.

Het overduidelijke nadeel van realtime HTTP compressie is het feit dat elke pagina gezipt moet worden voordat deze naar de client wordt gestuurd. Het gevolg is dat de response tijd iets oploopt. Op dit moment (s'nachts) is daar nog niets van te merken, maar dat kan anders tijdens de topdrukte overdag (wanneer er rond de 10 pagina's per seconde worden gerenderd). Aan de andere kant heeft HTTP compressie het voordeel dat de transfertijd veel korter is bij trage clients, waardoor de Apache kindjes sneller mogen sterven. Dit bespaart geheugen en CPU tijd. In de komende dagen willen we uitvogelen of HTTP compressie al bruikbaar is met de huidige (over)belasting van de servers.

HTTP compressie wordt nu ook gebruikt op het forum. Arjen heeft een optie in de preferences opgenomen waarmee je compressie desgewenst kunt disablen. In de nieuwe Topix versie heeft hij tevens de volgende updates en bugfixes aangebracht:

1.2.5zlib - 18 november 2000

• code: wat debug info verwijderd.
  
• code: mt_srand ipv srand. (=betere random getallen)
  
• got: Mozilla/Netscape6 laten alles nu ook goed zien
  
• bugfix: smileycode fout
  
• bugfix: smilies bij starten van topic en bij editten bericht
  
• bugfix: smilies stonden boven preview scherm
  
• bugfix: enter na 1e regeltje in quote
  
• bugfix: html href naar [.url=http://]url[/url] omzetten ging niet ok
  
• bugfix: / me bug bij quoten!
  
• bugfix: links bij search klopten niet helemaal

Reacties (67)

[ACM]

Nog een tip voor diegenen die achter een proxy zitten
Als ie modern genoeg is (bv squid 2.3) dan kun je "http1.1 over proxy" aanzetten (zit bij IE onder de use http1.1 in advanced options)

Dan krijg je zelfs door je proxy heen die compressie

[Anoniem: 5790]

beetje irritant dat hier steeds wordt geschreeuw "wat stoer dat jullie hiermee begonnen zijn" etc.

terwijl hans en ik er mee begonnen zijn!

t.net blijft het idee van "credit where credit is due" niet begrijpen

maar goed, ik zal dit soort dingen dan maar niet meer posten, ook goed!

[Peerke]

En jij hebt het ook weer ergens opgepikt lijkt me ...

--
"Credit where credit is due"

Dus ...
[chem]: Shit happens, it's life ....
T.Net: Credit where credit is due?

[originalmycroft]

Als alle internet sites zo iets nou toepasten, hadden we die spiegelchippies helemaal niet nodig gehad

[heuveltje]

zou toch wel eens tegen kunnen vallen, ik denk dat veel van die capaciteit word benut door (al dan niet ilegale) iso's,warez,mp3's,streaming audio en video,de graphics op de pagina enz.... en maar een klein gedeelte door de http zelf

[Ikarus]

Als ik het dus goed snap wordt nu eindelijk processor wat beter gebruikt (en is het dus niet zo'n overkill als eerst ) Maar ik vraag mij af of er niet iets van browser detection in het script kan (ik heb nu ff niet de mogelijkheid om het te testen of het er al in zit) dan kunnen alle browsers die 'content-encoding' niet ondersteunen toch de pagina viewen zonder &nocompr=true handmatig aan de url toe te voegen. Ik maak zelf wel eens gebruik van exotische browsers die dat zover ik weet niet supporten (arachne en zo)

* 786562 IkarusMaar dat is denk ik alles wat ik er aan kan opmerken

[Femme]

Hij checkt altijd of de browser HTTP_ACCEPT_ENCODING in de header meestuurt. Zoniet, dan krijg je een normale ongecomprimeerde pagina.

[Ikarus]

Goed ja dat zie ik nu ook (Whoops) ik ben niet echt wakker blijkbaar, maar wat verwacht je om 5:30 midden in de nacht

[TheGhostInc]

Inderdaad, nu wordt de processor eens gebruikt, ipv van die (ranzig dure) internet verbindingen.
Want wat heeft het voor nut om 5x zo veel data verkeer te creeren terwijl dat niet nodig is.


* 786562 TheGhostInc

[tex5]

Dit rocked! Heb soms wel lange pages met javascript doc writen kunnen versnellen wat resulteert in ongeveer dezelfde ratios maarja.. zoiets kost vet veel tijd als je changes doorvoert.

html compressie rocked hard, kost je totaal geen "admin" tijd Setup and forget

Dit is zeker interesting voor sites die erg veel pageviews hebben.. gezien de toch nog steeds hoge bandwidth kosten voor busy sites. Met zulke vette compressie ratio's betekent het dus dat je bv. 5 keer zoveel pageviews door je pijp kan sturen zonder extra kosten.. wat normaal, als je site bv. 2mbps doet, dus zou beteken dat je 10mbps nodig zou hebben. 2mpbs kost ongeveer 10.000 per maand.. (tweakers.net wordt heerlijk gesponserd maar dat even terzijde ) dus naja 10mpbs hmm 30.000 ofzo.. naja.. lijkt me duidelijk. Als de meeste pages dus lekker veel html containen is dit erg erg ERG vet

Wel vaag waarom dat nu opeens opduikt.. maja beter laat dan nooit

[Peerke]

Ik weet niet waar jij je server dan plaats, maar voor 640 Gigabyte verkeer (even grof omgerekend van 2 MBit bandwidth), betaal ik echt geen Fl 10.000,- hoor ! Je bent dan (voor bandbreedte only) ruim 3.000 gulden kwijt, en dan staat je servertje gewoon in Amsterdam ZO in een colo, met Uplinks naar:
- Level 3 (100 MBit)
- Cignal (100 MBit)
- GTS/Ebone (100 MBit)
- AMS-IX (1000 MBit, Gigalink)
Dus snel genoeg

[tex5]

Colo? Thats so last century

Maja, was maar een voorbeeld, 2mbps opzich aan bandwidth kost idd 3000/4000.

Als je een 34mbit fiber lijntje 2x redundant wil hebben naar waar je werkt/woont betaal je een behoorlijk extra als start. Nam dat ff mee met die 2mbps

[Anoniem: 1697]

Toevallig is er op 't werk net een 2 Mbit huurlijn aangesloten (Versatel). Kost 4500 per maand, excl. btw.

[tex5]

Inclusief 2mbps flatrate? dus dat je continue op 2mbps mag zitten? Ben nog geen ISP tegengekomen die dat voor zeg onder de 9k wil doen(lijn + 2mbps).

[looskuh]

NS doet dit vanaf versie 4.5 en IE vanaf versie 4 met uitzondering van de Mac varianten (boeiuh )

Ai... toch vervelend, want ik wilde het op m'n werk een beetje gaan promoten nav diezelfde thread. Maar heel onze design-afdeling zit op een mac. Dat feestje gaat niet door dus, want dat zou betekenen dat ze geen van onze pagina's zouden kunnen bekijken.

Het grootste probleem met nieuwe dingen is altijd de incompatibileit, en dus kan je nooit iets echt van de grond krijgen.

[tex5]

Nah, als de server ziet dat de browser het niet snapt gaat ie niet compressen.. dus compleet en 100% compatible eigenlijk Unless the mac browser _zegt_ dat ie het wel snapt tegen de server...

[GREENSKiN]

Dan is die browser gewoon een dikke oetlul

[smoove]

HTTP compressie zit standaard op IIS 5 niks nieuws

[ACM]

Er wordt ook nergens gezegd dat het nieuw is...
Voor tweakers is het nieuw. Maar voorderest niet...

[Hielko]

Dit zouden meer mensen moeten doen (HTTP compressie dan...)

Met m'n ISDN lijntje merk ik echt dat vooral lange pagina's een flink stuk sneller gaan .

[Peerke]

Sommigen providers ondersteunen op 'hun' inbelapparatuur 'softwarecompressie'. Dan gebeurd er ook zoiets, iets wordt compressed over je lijn gestuurd, wat ook veeel scheelt.

[Femme]

Het voordeel van compressie vooraf is dat je de hele file kunt inpakken waardoor je een veel hogere compressie ratio kunt halen dan wanneer je dat bij de provider (op de weg tussen server en client).

[Mr.Aargh]

yup , dus dan scheelt het niet alleeen voor de user maar ook voor de webserver (kortere connectieperiodes) en bandbreedte vanaf de server.
Dan is de ISP ook wat miinder traag .. want IPS's zijn altijd traag .. hehe

[nulkelvin]

Dit lijkt me een interessante ontwikkeling, m.a.w. kan je dus door het er in douwen van een zwaardere proc je webserver sneller laten lopen? Klinkt wel cool.

[Anoniem: 4988]

jihoe

zelfs met casema gaat tweakers nu als een tiet

normaal moet ik een eeuwigheid wachten voordat alle reacties op m'n schermpie getoverd worden, nu is het ff wachten en boem