Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 67 reacties

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 )

PHP4 Zend logo 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

Door Femme Taken

- Architect

Femme is in 1998 als oprichter met Tweakers begonnen en werkt tegenwoordig als ontwerper in het productteam van Tweakers. In de vrije tijd knutselt Femme fanatiek aan zijn domoticasysteem.

Moderatie-faq Wijzig weergave

Reacties (67)

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
Als alle internet sites zo iets nou toepasten, hadden we die spiegelchippies helemaal niet nodig gehad
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
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!
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?
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 :7
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 :)
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 :)
Toevallig is er op 't werk net een 2 Mbit huurlijn aangesloten (Versatel). Kost 4500 per maand, excl. btw.
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).
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 :)
Hij checkt altijd of de browser HTTP_ACCEPT_ENCODING in de header meestuurt. Zoniet, dan krijg je een normale ongecomprimeerde pagina.
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 :D
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
compressie rocks idd!!!

mijn waarden:
not compress length: 16555
compressed length: 5626
ratio: 1: 2.94
level 9

echt heftig zeg!! :9 :9
En probeer het dan nog eens op een nieuwsposting met veel reacties, bijv. www.tweakers.net/nieuws.dsp?ID=14486&debug=1 . Hij haalt daar nu 1:6,29!
haha, dat is nog nix. zie hiero:
www.tweakers.net/nieuws.dsp?t=974567279&ID=14488&debug=true

haalt ie bij mij 1 :9.9

keep up the good work!!!
ik bedoel dus eigenlijk 1: 9.9
Woow!

Uncompressed: 110187
Compressed: 11521

Dat is gewoon een 0 minder! Gaat lekker hoor... :)
femme, je hebt level op 9 gezet...
hoe zit dat ? is dat 't compressie nivo ? 1 is licht compressen, 9 is zwaar compressen ?
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 :).
Sommigen providers ondersteunen op 'hun' inbelapparatuur 'softwarecompressie'. Dan gebeurd er ook zoiets, iets wordt compressed over je lijn gestuurd, wat ook veeel scheelt.
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).
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 :z :Z
Pakt wel heftig veel cpu cycles, de httpd processen waren normaal iets van 0.nogwat%.. met mod_gzip gingen sommige gewoon lekker 20% van de cpu cycletjes op zitten grazen..

Dat met die php solution ook zo? Want als het zoveel power nodig heeft is het pretty useless als de server waar je het op doet ook nog andere cpu intensive dingen doet. Wordt nog maar een "in-between" server erbij :P

Server 1: Front end load balancer.
Server 2: Squid cache.
Server 3: Compressor.
Server 4: CGI/(whatever) processing.
Server 5: Database server.

}>
De meeste httpd's zitten op Appie tussen 0,5 tot 3% met dat PHP script.

Server load wordt in de toekomst niet zo'n probleem: 3x 1GHz Tbird/512MB webservers + Dual PIII-866 1,5GB dbase server + load balancer is waar we mee bezig zijn :9.
Heh, hmmmmmmmm.. vreemd waarom dat met mod_perl zoveel cpu pakt en met php niet, naja.. weer wat om uit te zoeken :)

--
Wat ik maar heb gedaan in de tijd dat ik niet kon reageren hier (t.net down).
--

Omdat ik alles met perl heb gedaan is php nie echt een optie, heb maar ff wat verder rondgesnuffeld op de site van de makers van de mod_gzip voor apache en het blijkt dat ze dus ook een soort "proxy/squid" achtig iets hebben. RCTPD, doet precies hetzelfde, compressen van html data maar dan niet als module of php script. Je direct dat prog naar je webserver poort 8000 ofzo en het prog zelf draait dan op 80 en "tunneled" alle requests om ze ondertussen nog ff te compressen net voor ie ze terugstuurt naar de browser.

Opzich is dit erg handig, je hoeft niet te kloten met apache en/of php. En alles werkt gewoon direct, makkelijk uit/aan te zetten etc. Nadelen weet ik nog niet :P

Lekker die specs, zal idd wel ff duren voordat dat weer vol zit, of uhm nah, sneller meer pageviews ruled harder ;)
Mja, kreeg toch wat klachten binnen van mensen met IE op de "Mac" (wasda?).. ze kregen dus een window met de vraag welk prog het bestand moet openen..

Blijkbaar werkt de standalone prog niet zoals de php fix :(

Tis ook altijd wat met die Macs :P
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. ;(
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... :P
Dan is die browser gewoon een dikke oetlul ;)
Volgens mij heeft iedereen dezelfde compressie waarden hoor ;)

Wat ik vooral merk is dat als de pagina eenmaal begint dat hij er dan ook meteen staat. Ik heb vaker last van trage responds tijden waarna ook het tevoorschijn komen van de pagina erg langzaam gaat. Dat heb ik op het moment niet. Het duurt even, maar daarna staat het er meteen. Ik weet wel wat ik ga doen op mijn servertje zometeen! }>
Volgens mij heeft iedereen dezelfde compressie waarden hoor :)
Yep, maar ligt eraan hoeveel reacties jij ziet (kun je instellen in preferences) :)

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True