http compression - it rocks

[chem]

mja, ik & hanszel hebben ff lopen spieleren met http-compression, vanuit zowel .html als .php files.

En er is goed nieuws; het draait als een kanon. Ik heb een forum nu met gzip-enabled (http://www.glitter-it.nl/forum/) en daar haal ik ca. 75% compressie van HTML files, wat je dus echt merkt - zowel via mij brakke casema als de toch wel snelle kabelmodems als de univ. leiden...

oftewel: dit rockt! bijna geen extra serverload (nou ja, tov de voordelen niet) heel eenvoudig toe te passen (simple regeltje vooraan en onderaan je file in php) en echt flink wat snelheidswinst...

maw, kijk er eens naar als je een eigen server hebt, je meot php wel met zlib compilen, en apache moet ook er voor aangepast worden (voor html alleen, voor php niet)

[Arjen]

Voor de mensen die niet weten waar chem 't over heeft even een paar links..

http://apachetoday.com/news_story.php3?ltsn=2000-10-13-002-01-NW-HE-SW
(goeie uitleg + links naar meer info)
http://php.weblogs.com/stories/http_compression
(scriptvoorbeeld)

Ik wil er zelf ook graag mee experimenteren voor het forum, maar Rick heeft niet zo'n haast met het recompilen van PHP met zlib support heb ik 't idee.

[chem]

arjen> tsja, ik zou me er wel aan wagen, de performance voor de gebruiker is echt ZOVEEL beter, en zeker met de javascript-aanpak van topix kun je een flinke compressie verwachten...

btw jorma werkt ook bij 'ons' (hans/ik) en hij heeft me leuke ideetjes gegeven voor m'n foraatje (nix illegaals hoor!)

[The Source]

Ik heb de artikelen gelezen en ben erg geinteresserd... need more info...

Hebben jullie meer links en ervaringen?

[Olaf van der Spek]

<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Op 14 november 2000 20:21 schreef Arjen het volgende:
Voor de mensen die niet weten waar chem 't over heeft even een paar links..

<a href="http://apachetoday.com/news_story.php3?ltsn=2000-10-13-002-01-NW-HE-SW" target="_blank">http://apachetoday.com/news_story.php3?ltsn=2000-10-13-002-01-NW-HE-SW</a>
(goeie uitleg + links naar meer info)
<a href="http://php.weblogs.com/stories/http_compression" target="_blank">http://php.weblogs.com/stories/http_compression</a>
(scriptvoorbeeld)

Ik wil er zelf ook graag mee experimenteren voor het forum, maar Rick heeft niet zo'n haast met het recompilen van PHP met zlib support heb ik 't idee. :)[/quote]Ik heb net op die eerste site die twee files opgevraagd en ik kon echt bijna geen verschil in snelheid merken (via een snelle verbinding).
Dat er op zulke pages erg goede compressie mogelijk is kan ik goed snappen met zulke HTML. Als ze wat CSS zouden gebruiken zouden ze volgens mij ook de page behoorlijk wat kleiner kunnen maken (van 664 kb naar 396 kb).

Is het niet mogelijk de Apache server de compressie te laten uitvoeren voor scripts in plaats dat je daarvoor alle scripts aanpast?<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>The Web is as strong as its weakest link. This has and always will be the last mile to the consumer's desktop. [/quote]Volgens mij is dat nu al niet het geval met bijvoorbeeld kabel en ADSL.<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Compression consumes only a few milliseconds of CPU time [/quote]Only a few? Op een beetje drukke server heb je volgens mij niet zoveel CPU time over, of zie ik dat verkeerd?

[The Source]

Wat ik heb begrepen...

compressie gebeurt offline en dan wordt het bestand gecromprest online gezet.

decrompressie gebeurt bij de bezoeker zelf. Is dus geen server belasting.

[tomato]

Ik weet niet hoor, maar maakt het nou echt zoveel uit? Mij lijkt het ook allemaal heel tof en het zal best IETS uitmaken, maar merkt de bezoeker daar nou echt iets van?
Het lijkt mij dat je op een gemiddelde pagina (een gemiddelde pagina bevat ook images) veel langer bezig bent met het downen van de images dan met de HTML zelf. Heeft iemand misschien harde cijfers?


compressie gebeurt offline en dan wordt het bestand gecromprest online gezet.

Dat kan denk ik niet. Wanneer wordt het volgens jou dan gecomprimeerd (begrijp ook niet helemaal wat je bedoelt)? Op het moment dat je een nieuw HTML bestand opload of wijzigt? Lijkt me erg onwaarschijnlijk.
Nee, de server zal het moeten comprimeren op het moment dat een bezoeker een request zend (on the fly dus) en dat zal best wat extra load opleveren. Maar dat zie ik niet echt als probleem overigens, want veel load zal het niet veroorzaken...

edit:

Sorry als ik wat dingen duidelijk uit de links had kunnen halen, maar ik heb gewoon (op dit moment) echt geen tijd om die artikelen door te lezen.
Zag overigens wel dat in het Apache Today artikel wat cijfers genoemd worden en dat er twee manieren zijn om te comprimeren:
* On the fly (vooral bij dynamic content)
* Pre-compressed (bij statische content)
Ga het binnenkort lezen...

[Martin Sturm]

ok, hij is wel snel, maar niet veel sneller dan GOT. Echter dit komt waarschijnlijk omdat ik op een 34mbit lijntje zit, met ongeveer 100 man. (nieuwe lijn bij isp waar ik werk, die getest moet worden.. morgen is het weer helemaal vol.. )
Maar het langst waar mijn browser meestal op wacht is de reactie van de server.. het verzenden duurt meestal niet echt snel.

[The Lord]

Ik heb die HTTP compressie zo'n jaar geleden al eens getest (IIS 4.0 op NT Server 4.0).

Het werkt goed, maar ik heb er vanaf gezien, omdat de meeste browsers er toen nog niet goed mee werkten.

De meeste GZIP libraries / filters ondersteunen zowel static als dynamic.

Static - kun je vooraf loslaten op je bestanden. Perfect voor niet statische inhoud (geen extra CPU belasting).

Dynamic - is 'on the fly'; de pagina wordt ge-ZIP't zodra die wordt opgevraagd. Perferct voor dynamisch opgebouwde pagina's (PHP, CF, ASP, ...)

Onder IIS gaat het ISAPI filter na het produceren van de HTML aan de slag met de compressie. Welke data het filter comprimeert is volgens mij afhankelijk van de http-header data. Ik kan mij dus ook voorstellen dat XML of XHTML standaard niet wordt gecomprimeerd. Wellicht geldt dit ook voor PHP. Dan moet je dus expliciet aan het filter vertellen dat deze MIME types ook moeten worden gecomprimeerd.

[Olaf van der Spek]

<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Op 15 november 2000 13:49 schreef The Source het volgende:
Wat ik heb begrepen...

compressie gebeurt offline en dan wordt het bestand gecromprest online gezet.

decrompressie gebeurt bij de bezoeker zelf. Is dus geen server belasting.[/quote]Wat ik dus heb begrepen is dat het realtime gebeurt. Offline compressie is al heel lang mogelijk, maar dat wordt niet gebruikt omdat het lastig te onderhouden is (je moet telkens comprimeren als je een HTML page wijzigt).

Waar het hier juist om gaat is realtime compressie voor bijvoorbeeld dynamische content.

[Hans]

Die experimentjes die ik en Chem gedraait hebben zijn goed bevallen. Heb alleen wat trubbels gehad met mod_gzip, dit is een module voor Apache die dit dus allemaal on the fly doet voor zowel static HTML als CGI output (helaas nog niet voor mod_phpx).

De module is op zich ok, maar ik merkte wat problemen op een UBB forum dat op de desbetreffende server staat. Door de compression lijkt het erop dat de cache control over de zeik gaat, waardoor browsers het niet meer trekken ofzo. Bij het aanmaken van een nieuw topic was deze niet direkt zichtbaar, pas bij een nieuwe sessie (browser dicht-open).

Nou is mod_gzip ook nog heel pril (ze zijn er net een maand mee bezig) en dus een work in progress, maar de resultaten waren goed!

[Olaf van der Spek]

Ik dacht te hebben gelezen dat mod_gzip alleen voor static content was, maar ze hebben het dus schijnbaar geupdate.
Als ik het goed begrijp is er dus geen aanpassing van CGI of PHP scripts nodig voor deze compressie?

En over het algemeen snap ik best dat compressie voor langzame verbindingen erg handig is, maar voor bijvoorbeeld CVS wordt het ook afgeraden omdat het te veel server belasting betekent (dacht ik).

[Hans]

<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR>Op 15 november 2000 14:58 schreef OlafvdSpek het volgende:
Ik dacht te hebben gelezen dat mod_gzip alleen voor static content was, maar ze hebben het dus schijnbaar geupdate.
Als ik het goed begrijp is er dus geen aanpassing van CGI of PHP scripts nodig voor deze compressie?[/quote]PHP output compressed ie op dit moment alleen als je PHP als CGI draait.

[Olaf van der Spek]

Ok, maar daar wordt dus nog iets aan gedaan (neem ik aan).
Is die mod_gzip al stabiel genoeg om in een produktie server gezet te worden?

[chem]

nee, hans, php wordt door php ZELF gecompressed.
On the fly, mbv. een script dat kijkt of de browser gzip of zip ondersteunt en met obstart() de hele content opvangt, compresst, en wat header truukjes doet + flusht.
Nix met mod's enzo!

en tsja, dat het forum niet veel sneller dan GOT is heeft te maken met de beest van een server waar GOT op draait, en het feit dat GOT reeds 'compressie' toepast dmv. de javascript-write's ipv de harde html die ik gebruik. Het zoyu echter allemaal een stapje sneller kunnen

nee, breedbanders merken er uiteraard veel minder van. 0,5 of 0,1 seconden merke jie niet echt. 5 of 1 seconden wel...

cpu load ga ik bekijken. Ik vermoed (ik hoop) dat het niet veel uitmaakt, tov. de rest van het script - cq. de load wordt bv. 5% meer. Daarbij kun je de compressie instellen van 0-9. Ik kijk dan naar hoeveel LANGER het script draait. (parse time)

maw - voor server die misschien een beetje speling hebben, is het wellicht een idee, zeker voor de grotere pages en bv. 90% tekst pages als dit forum....

[chem]

pre-compressed is beetje nutteloos. Kost veel tijd, zeker als je files vaak wijzigen. Voor .js files kan het weer wel voordelen bieden, aangezien die soms flink groot kunnen zijn, en amper wijzigen (startpagina?!?!)

[Olaf van der Spek]

Met wat automatische features kan ik me best voorstellen dat pre-compressed best erg nuttig kan zijn hoor.
Jij upload naar een bepaalde directory en je runt een script dat alles dan compressed wegschrijft naar de gewone document root.

[chem]

Femme Taken

had een flinke posting gedaan. ik heb die nog een keer erin gezet... de nummertjes bij een flinke file:

Not compress length: 109232
Compressed length: 36117

Wat me opviel (wat ik niet verwachtte) is dat netscape nog steeds 'on the fly' rendert cq. het bestand wordt niet eerst helemaal binnengehaald en vv. ge-decompressed, maar het gebeurt terwijl je het binnenhaalt... nice!

http://www.glitter-it.nl/forum/forum.php?action=list_messages&TopicID=10

nieuw feature op m'n forum (dankzij teasz) vanaf dit weekend - notification niet alleen via email & icq, maar ook via SMS...

[Verwijderd]

hmz...buiten dat die http compressie erg interessant is, volgens mij kan het namelijk wel veel schelen, wil ik wel ff weten hoe jij die sms-notification voor mekaar hebt gekregen

[Femme]

<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR> Wat me opviel (wat ik niet verwachtte) is dat netscape nog steeds 'on the fly' rendert cq. het bestand wordt niet eerst helemaal binnengehaald en vv. ge-decompressed, maar het gebeurt terwijl je het binnenhaalt... nice! [/quote]Dat vroeg ik me dus ook af.

HTTP compression schopt major ass . Het scheelt netwerk traffic en de duur van de transfers zijn korter waardoor de apache kindjes sneller kunnen sterven bij het bedienen van een trage clients.

[chem]

ik weet helaas (te) weinig van php en httpd thredas en cpu-load...

maar enigzins speculerend - is de tijd dat httpd MINDER tijd bezig is met het versturen van de file, wellicht heft dat weer de compresie load op?

Misschien een balans vinden in mate van compressie en cpu load?



over het SMS-en, ik heb een server gevonden die zo lek als een tiet is. Enkel de URL aanroepen & da's alles. Met fopen() dus.
Daarnaast ga ik werken (na het weekend) aan een script dat ook met MTN etc. om kan gaan (dus een socket openen, cookies aannemen en returnen etc.)

Ik hoop zover te kunnen gaan (haalbaarheid ) om een proxy te kunnen gebruiken zodat niet 1 IP nummer wordt geband, en iig. verschillende SMS-servers at random lastig te vallen, onder verschillende accounts - na menig uurtje http-tcp/ip traffic turen, zie ik dat alle servers op dezelfde wijze werken qua verificatie.
Nix dat niet omzeild kan worden


Olé!

btw als iemand interesse in het forum heeft hehehe

[chem]

&nocompr=123 toevoegen aan de URL zet compressie uit

bv:
http://www.glitter-it.nl/forum/forum.php?action=list_messages&TopicID=10&nocompr=123

voor diegene die denken dat 't niet scheelt

[Verwijderd]

He chem,

Ik denk dat we nog wel een maandje aan het forum moeten sleutelen voordat we het kunnen aanbieden. Ik heb nog vele ideeen en de 1.0 moet echt barsten van functionaliteit en de code moet top zijn. Ook moet er nu nog een betere admin komen ed. Dan pas kunnen we er wat mee gaan doen denk ik. Misschien een leuk domeintje starten waar mensen hun forum op kunnen draaien? En dus een kick-ass forum met goede admin!

[chem]

teaz> jah duh :-)

maar eea. komt er nog, oa. meer prefs etc. en hij wordt echt 3x beter dan topix hahaha

maar ff terug naar het subject

[Arjen]

http://www.remotecommunications.com/apache/ab/

Met deze aangepaste Apache Benchmark kan je de compressie testen enzo. Je krijgt dan ook te zien hoelang het duurt voordat het request verwerkt is. Als je daarna dezelfde test draait zonder compressie krijg je wel een aardig beeld van de serverload die zlib veroorzaakt denk ik..

[The Lord]

Uhmm, Chem. Zonder compressie kan ik die pagina véél sneller laden. Zo'n 1/3 van de tijd...

Maar dat komt waarschijnlijk omdat ik vals speel; een 34Mbps linkje met actief cachende proxy voor mezelf.

[UPDATE 1]
Hûh? Ik dacht dat het wel eens iets met de tunneling van HTTP1.1 door de proxy te maken had, maar nee. Dat maakt geen bal uit.

Ik snap het rare verschil niet zo goed.

[UPDATE 2]
Na wat stuntelen nog steeds hetzelfde resultaat. Het viel me ook op dat IE 5.5 eerder de pagina begint te renderen als deze niet gecomprimeerd is.

[UPDATE 3]
Ik ga morgenochtend ff direct op die 34Mbps proberen, zonder proxy en firewall.

[Femme]

Mét compressie duurt het vrij lang voordat er begonnen wordt met het binnenhalen van de pagina, maar het binnenhalen zelf gaat véél sneller. Staat die server onder een heftige load?

[duderuud]

Forum is inderdaad snel zeg!:)

[Olaf van der Spek]

Op woensdag 15 november 2000 20:09 schreef chem het volgende:
Femme Taken

had een flinke posting gedaan. ik heb die nog een keer erin gezet... de nummertjes bij een flinke file:

Not compress length: 109232
Compressed length: 36117

Wat me opviel (wat ik niet verwachtte) is dat netscape nog steeds 'on the fly' rendert cq. het bestand wordt niet eerst helemaal binnengehaald en vv. ge-decompressed, maar het gebeurt terwijl je het binnenhaalt... nice!

http://www.glitter-it.nl/forum/forum.php?action=list_messages&TopicID=10

nieuw feature op m'n forum (dankzij teasz) vanaf dit weekend - notification niet alleen via email & icq, maar ook via SMS...

Hoe doe je die ICQ notification precies? Heb je geen problemen als je veel notifications in een beperkte tijd moet versturen?

Kun je sommige fields (user registratie) niet wat breder maken?
Ze zijn nu 20% van mijn scherm ofzo.

[Olaf van der Spek]

Op woensdag 15 november 2000 23:13 schreef Femme het volgende:
Mét compressie duurt het vrij lang voordat er begonnen wordt met het binnenhalen van de pagina, maar het binnenhalen zelf gaat véél sneller. Staat die server onder een heftige load?

Waarom moet het zo lang duren voordat begonnen kan worden met versturen?
Volgens mij ondersteund de gebruikte compressie methode (zlib?) het gedeeltelijk verzenden voordat alles gecomprimeerd is.

[chem]

hai allen,

okay een kleine update dan.

ja, de RESPONS tijd ligt hoger. De hele file wordt in een var gepropt (met php dmv ob_start()). Aan het eind van de file wordt alles gecompresst en geflusht.

Als het UIT staat, die compressie, dan beginnen de html headers etc. al te versturen, en de body etc. Daarbij heb ik de file zo pgezet dat elke msg 1 tabel is, wat sneller rendert in netscape ipv 1 mega tabel.

Van de load van die server kan ik nix zeggen :-)

ICQ doe ik via een mail() actie. Het forum loopt niet zo storm dus dat zit wel goed . Ik heb nu die notify uitgebreid naar standaard 1 bericht, maar met een checkbox meerdere berichten.

Want als je een notify krijgt, ga je toch kijken en dan kun je weer om een notify vragen bij je nieuwe bericht. Mocht je echter altijd een bericht willen krijgen dan check je hem ff aan.

nog vragen?

ps. ik ga nu ff aan tag balancing werken (weer) en dan gooi ik die leuke [php ] tag ook in m'n foraatje!

[Tom]

Gaaf zeg, maar wat is er dus voor nodig? Apache met een bepaalde library gecompiled, een include in je PHP filetje en een commando die een function aanroept om de boel te compressen en door te sturen?

Enneh; de client heeft niets nodig? Zit gewoon in IE/NS ingebouwd al?

[Hans]

Op donderdag 16 november 2000 13:39 schreef chem het volgende:
Van de load van die server kan ik nix zeggen :-)

Ikke wel en ja, die bak heeft het af en toe behoorlijk druk. Voorheen draaide de RC5 stats voor [e-mail] er ook op, maar die heb ik maar ff verkast naar een andere server om deze te sparen

[Olaf van der Spek]

Ja, in de clients zit het al ingebakken.

[Hans]

Op woensdag 15 november 2000 15:35 schreef chem het volgende:
nee, hans, php wordt door php ZELF gecompressed.
On the fly, mbv. een script dat kijkt of de browser gzip of zip ondersteunt en met obstart() de hele content opvangt, compresst, en wat header truukjes doet + flusht.
Nix met mod's enzo!

Ja DUH! Don't act like i dont know... Maar het zou nog meer kont schoppen als mod_gzip zover is dat ie ook de output van mod_php kan compressen, want php als CGI draaien zuigt aarsch

[Hans]

Op donderdag 16 november 2000 14:17 schreef Tom het volgende:
Gaaf zeg, maar wat is er dus voor nodig? Apache met een bepaalde library gecompiled, een include in je PHP filetje en een commando die een function aanroept om de boel te compressen en door te sturen?

Enneh; de client heeft niets nodig? Zit gewoon in IE/NS ingebouwd al?

PHP compilen met Zlib, stuff includen die de boel gzipt, en sturen. Alle clients die HTTP/1.1 ondersteunen (en dat is al ff zo) kunnen dit aan.

[Tom]

Op donderdag 16 november 2000 14:19 schreef Hans het volgende:
[e-mail]

hmmken jij een Jasper?

[Hans]

Zie hier:

Is Compression Built into the Browser?
Yes. Most newer browsers since 1998/1999 have been equipped to support the HTTP 1.1 standard known as "content-encoding." Essentially the browser indicates to the server that it can accept "content encoding" and if the server is capable it will then compress the data and transmit it. The browser decompresses it and then renders the page.

Only HTTP 1.1 compliant clients request compressed files. Clients that are not HTTP 1.1 compliant request and receive the files un-compressed, thereby not benefiting from the improved download times that HTTP 1.1 compliant clients offer. Internet Explorer versions 4 and above, Netscape 4.5 and above, Windows Explorer, and My Computer are all HTTP 1.1 compliant clients by default.

To test your browser, click on this link (works if you are outside a proxy server):

code:

http://12.17.228.52:7000/

[Hans]

Op donderdag 16 november 2000 14:25 schreef Tom het volgende:

[..]
hmmken jij een Jasper?

Eh, ja, die zit op het moment tegenover me

[Tom]

Op donderdag 16 november 2000 14:26 schreef Hans het volgende:

[..]
Eh, ja, die zit op het moment tegenover me

ah hehe lache doet'm maar de groete van me

[Jasper]

Op donderdag 16 november 2000 14:27 schreef Tom het volgende:
ah hehe lache doet'm maar de groete van me

En gekregen!

Hoestnou?

[Verwijderd]

Dit is allemaal al oud nieuws mensen
bijv .wrl (VRML_files) kan je ook gegzipped versturen, scheelt ook massa's aan bytes :]
Maar goed niet echt iets nieuws..
Vaak is't overbodig omdat'r toch nietzoveel info op een page staat (over het algemeen) en de cpu veel zwaarder belast wordt (van de server)
Maar goed kies zelf wat je doet, ik vind't niet erg als je't doet me me casema

[Tom]

Op donderdag 16 november 2000 14:32 schreef Jasper het volgende:
Hoestnou?

Goed hoor, maar laten we maar weer ontopic gaan anders word de topicstarter boos

[tomato]

Op donderdag 16 november 2000 14:26 schreef Hans het volgende:

[..]
Eh, ja, die zit op het moment tegenover me

Met Jasper was je toch ooit nog eens begonnen aan een project? Stond er een mooi plaatje met wat bliksemschichten en 'coming soon'. Misschien beetje inge-:z ?

[tomato]

Hmmm...als ik dit zo lees krijg ik het gevoel dat het (mede) om een psygologische snelheidswinst gaat (voor het gevoel). Chem zei ook al iets dat het gewoon fijner aanvoelde geloof ik (kon ook iemand anders zijn).
Het is nu dus zo dat de response tijd wat groter is maar dat het vervolgens veel sneller binnenkomt. Kan best dat het overall helemaal niet sneller is (iig niet veel) en dat het toch sneller overkomt. Eigenlijk maakt dat natuurlijk niet uit, want het gaat er natuurlijk gewoon om hoe de gebruiker het ervaart (eeuwenoud gegeven ).

[Hans]

Op donderdag 16 november 2000 15:00 schreef tomato het volgende:

[..]
Met Jasper was je toch ooit nog eens begonnen aan een project? Stond er een mooi plaatje met wat bliksemschichten en 'coming soon'. Misschien beetje inge-:z ?

Hehe, ja sort of er draaien wel wat dingen op dat domein, maar dan op subdomeintjes enzo. De rest is idd ingekakt wegens drukte op school en werk. Ook mij grootse plannen mbt phpdev.nl staan in de koelkast

Maareh, tis niet alleen maar 'in the head', check deze links maar eens:

Real time Web server content acceleration test:

Before(zonder compressie): http://12.17.228.53:8080/music.htm
After(met compressie): http://12.17.228.53/music.htm

[Jasper]

Op donderdag 16 november 2000 14:36 schreef Tom het volgende:

[..]
Goed hoor, maar laten we maar weer ontopic gaan anders word de topicstarter boos

Chem boos? Eheh!

Whoop his ass!

[Verwijderd]

<quote>
Tomato:
Het lijkt mij dat je op een gemiddelde pagina (een gemiddelde pagina bevat ook images) veel langer bezig bent met het downen van de images dan met de HTML zelf. Heeft iemand misschien harde cijfers?
</quote>

Een image is meestal (99%) al gecomprimeerd (JPG en GIF zijn gecomprimeerde image-formaten; BMP niet, maar dat wordt dus ook bijna niet gebruikt op het web.) Het grote voordeel van tekstbestanden comprimeren is dat de winst errug hoog is. Meestal wel rond de 50% (afhankelijk van de grootte van je HTML/tekst file).
Een paar voorbeeldjes (effe met WinZip):
[in bytes]
ongecompr gecompr procent
95 82 14%
985 479 51%
1010 494 51%
162741 36807 77%
tweakers.net home
22280 6182 72%

Het scheelt toch weer een hele hoop en dat kunnen we best gebruiken op het web.

[tomato]

Op donderdag 16 november 2000 15:36 schreef Vrep het volgende:
<quote>
Tomato:
Het lijkt mij dat je op een gemiddelde pagina (een gemiddelde pagina bevat ook images) veel langer bezig bent met het downen van de images dan met de HTML zelf. Heeft iemand misschien harde cijfers?
</quote>

Een image is meestal (99%) al gecomprimeerd (JPG en GIF zijn gecomprimeerde image-formaten; BMP niet, maar dat wordt dus ook bijna niet gebruikt op het web.) Het grote voordeel van tekstbestanden comprimeren is dat de winst errug hoog is. Meestal wel rond de 50% (afhankelijk van de grootte van je HTML/tekst file).
Een paar voorbeeldjes (effe met WinZip):
[in bytes]
ongecompr gecompr procent
95 82 14%
985 479 51%
1010 494 51%
162741 36807 77%
tweakers.net home
22280 6182 72%

Het scheelt toch weer een hele hoop en dat kunnen we best gebruiken op het web.

Ja, dat klopt, maar als je de totale grootte van je pagina op 100 zet en alle HTML en andere tekstbestanden (bijv jscripts) representeren daarvan 10 (lijkt me nog veel, zou eigenlijk even moeten kijken hoe die verhouding gewoonlijk is) dan heb je er nog niet veel aan als je die 10 dan voor 70% kunt comprimeren. Ok, je hebt er wel iets aan en de images kunnen ook pas geladen worden als de HTML eenmaal binnen is, dus wat dat betreft helpt het wel.
Jpeg en GIF hoef je niet te proberen te comprimeren en dat gebeurt ook heus niet met http compression (hoop ik tenminste niet ).
Het probleem hiervan is dat het natuurlijk erg lastig te benchmarken is. Als je het zelf doet komt het al snel op gevoelswaarden aan en daar heb je voor een echte benchmark natuurlijk niet veel aan (hoewel het eigenlijk wel is waar alles om draait, dus als je het zo bekijkt mag van mij alles 10% lanzamer als het maar sneller lijkt ). Daarnaast is de snelheid voor de client (op de server kun je dit natuurlijk niet benchmarken) van veel factoren afhankelijk. Je zult echt geautomatiseerd moeten gaan testen en dit lang achter elkaar.
Begrijp me niet verkeerd, ik denk heus niet dat het allemaal onzin is (vind het eigenlijk zelfs wel heel cool om eens te proberen), maar ik denk dat je er toch kritisch naar moet kijken.

[chem]

Op donderdag 16 november 2000 15:46 schreef tomato het volgende:
[.[..].]
Begrijp me niet verkeerd, ik denk heus niet dat het allemaal onzin is (vind het eigenlijk zelfs wel heel cool om eens te proberen), maar ik denk dat je er toch kritisch naar moet kijken.

hmz, dat is altijd nodig toch?

Om even door te breien op de berekening hierboven - als je idd een page hebt van zeg 100 kb itt, en de html is 20 kb dan slaat het relatief niet in als een bom - HOEWEL, als je eenmaal die plaatjes hebt gecached, en de html verandert DAN haal je wel snelheidswinst.

De download-delta is dan wel de compressiewinst.

En ik zit hier met IE en NS op een Mac. IE5 is VEEL sneller dan IE, maar mijn forum is sneller op NS omdat de files kleiner zijn. IE5 @ mac is 1 van de zeer weinig browsers die geen gzip ondersteunen. IE zuigt toh

btw, je kunt makkelijk een prefje maken of mensen wel/geen compressie willen, voor diegene die in hun 1tje een 1 gbit lijntje hebben

[tomato]

voor diegene die in hun 1tje een 1 gbit lijntje hebben

Ja, dat heeft niemand toch? Toch?!?

HOEWEL, als je eenmaal die plaatjes hebt gecached, en de html verandert DAN haal je wel snelheidswinst.

Daar heb je gelijk in. Op een forum (veel pagina's achter elkaar opvragen EN in verhouding veel tekst, weinig images) zal het dan ook veel nuttiger zijn dan op veel andere pagina's.

IE5 @ mac is 1 van de zeer weinig browsers die geen gzip ondersteunen.

Wat gebeurt er dan eigenlijk? Ziet de server dat en wordt er dan gewoon niet gecomprimeerd? Lijkt me wel, anders zou het wel lekker zijn...

[Jasper]

Op donderdag 16 november 2000 16:12 schreef chem het volgende:IE5 @ mac is 1 van de zeer weinig browsers die geen gzip ondersteunen. IE zuigt toh

Volgens mij zuigt de mac gewoon!

[chem]

Op donderdag 16 november 2000 17:59 schreef tomato het volgende:
Wat gebeurt er dan eigenlijk? Ziet de server dat en wordt er dan gewoon niet gecomprimeerd? Lijkt me wel, anders zou het wel lekker zijn...

mijn php script (nou ja, het door mij geleende script;)) check of de browser in de header meestuurt of-ie wel/niet gzip ondersteunt, en dus wel/niet compresst.

[GiLuX]

hmmm,

net ff php4.03pl1 gerecompiled met zlib en het volgende script ( http://leknor.com/code/php/view/class.gzip_encode.php.txt ) aan mijn forum toegevoegd maar ik merk weinig verschil.

is er een manier om dit te meten?

[chem]

die freebsd loadaverage bepaler vind ik wel interessant...

edoch ik heb compressie op 9 staan met debug aan, dan staan de voor/na getallen er bij...

ik heb m'n scriptje ook van www.hotscripts.com (ff zoeken op http comp)

[GiLuX]

damn,
helemaal niet gezien...

ok staat op 9 en true maar ik zie nergens uotput, waar staat dat bij jou? onderaan bovenaan?

[Femme]

De nieuws pagina's op Athena gebruiken nu ook compressie (vergelijk met + &nocompr=true). Het scheelt gigantisch (al snel meer dan 4 seconden bij een artikel met veel reacties) op mijn ISDN lijntje. De vertraging in response tijd valt ook erg mee als de server het niet druk heeft.

Dat de plaatjes niet verder gecomprimeerd worden boeit trouwens niet zoveel omdat die dingen toch gecached worden (vrijwel alle pics maken vast deel uit van de layout).

[Arjen]

Total transferred: 8035026 bytes
HTML transferred: 7599603 bytes
Requests per second: 10.09
Transfer rate: 81.10 kb/s received

Total transferred: 3263227 bytes
HTML transferred: 2784177 bytes
Requests per second: 9.44
Transfer rate: 30.82 kb/s received

Bij het in totaal opvragen van 1000 keer dezelfde dynamische pagina met 5 clients. Welke resultaten bij de compressie horen lijkt me wel duidelijk. Het is dus iets trager, maar met een paar stevige procs in de servers kan het makkelijk. Verder is hier natuurlijk geen rekening gehouden met evt. trage verbindingen. Als de html daar in 5 sec. ipv in 10sec. binnen is, gaat het aantal request/sec. natuurlijk omhoog. In het echt zal http-compressie dus sneller zijn denk ik.

[Femme]

Op de t.net nieuws pagina haalt-ie nu compressie ratio's tussen 1:5 en 1:6 (zie status bar).

[The Lord]

De 4e update dan maar :

Die compressie werkt best goed. Maar die 34 Mbit kan veel meer uit een lichte of flink belaste server trekken als dit uncompressed is (zeker als zo'n server aan een STM-1 zit ofzo).

Ik heb het geprobeerd door ff een test server hiervoor te gebruiken (dual PPro) en die aan een 10 Mbps link te hangen. Dan is compressed dus véél sneller dan uncompressed.

Conclusie : Dit was te verwachten

Linkje voor MS IIS 4.0 liefhebbers :

http://search.support.microsoft.com/kb/psssearch.asp?SPR=iis&T=B&KT=ALL&T1=7d&LQ=compress&S=F&A=T&DU=C&FR=0&D=sitemcis%2Bor%2Bproxysvr%2Bor%2Biis&LPR=%22internet+information+services%22+or+%22internet+information+server%22&LNG=ENG&VR=http%3A%2F%2Fsupport.microsoft.com%2Fsupport%3Bhttp%3A%2F%2Fsupport.microsoft.com%2Fservicedesks%2Fwebcasts%3Bhttp%3A%2F%2Fsupport.microsoft.com%2Fhighlights&CAT=Support&VRL=ENG&SA=GN&Go.x=35&Go.y=29

[Tom]

* Tom is overtuigd, het is koel

[tomato]

Ok, ik ben overtuigd van het nu ervan . Tweakers.net laadt echt sneller. Al denk ik wel dat je er met een 33 of 56 k modempje er meer van merkt dan wanneer je direct met een 100MB/S kaartje op een klein intranet zit (dan is het misschien zelfs langzamer).

[Femme]

Athena heeft 't nu redelijk druk en toch merk ik bijna niets van de negatieve effecten van compressie (met debug 2x compressie).

[chem]

heeft chem dan toch wel eens goede idee-en?



uhm

ja uhm

[Arjen]

Op vrijdag 17 november 2000 10:38 schreef tomato het volgende:
Ok, ik ben overtuigd van het nu ervan . Tweakers.net laadt echt sneller. Al denk ik wel dat je er met een 33 of 56 k modempje er meer van merkt dan wanneer je direct met een 100MB/S kaartje op een klein intranet zit (dan is het misschien zelfs langzamer).

Jep, daar ben ik het helemaal mee eens. Geldt trouwens ook als je bandbreedte aan serverkant te klein is (wat bij vuurwerk gelukkig niet het geval is..). In Topix komt waarschijnlijk gewoon een optie onder preferences waarmee je het uit kan schakelen als dat voor jou sneller is.

[Norjee]

Hehe dat sciptje is idd een leuk speeltje...

Mijn site (bijna alleen maar text) is er echt een beetje boel sneller door geworden
(maar dat merk ik al snel met mijn antieke analoge modempie)

Soms laat de server wel ff op zich wachten
Ben benieuwd hoe het overdag gaat.....

[Jasper]

Op vrijdag 17 november 2000 14:19 schreef chem het volgende:
heeft chem dan toch wel eens goede idee-en?



uhm

ja uhm

Wat een koooning die chem met zijn meester uitvindingen...

[GiLuX]

en als je op bandbreedte moet afrekenen scheelt dat aan het eind van de maand ook een boel, niet? als je in NL host.

[Aaargh!]

Als compressie aangaat op GoT, kan dan die akelige javascript zooi eruit ?

Ik browse liever met javascript uit (ivm security) plus dat lynx er niets mee kan.

[Ceaser]

Die compressie komt precies op het goeie moment nu casema de download limiet gaat doorvoeren;)

[ACM]

Wat ik ondertussen wel doorheb is dat een webserver met apache behoorlijk zwaar belast kan worden door al die threads (die met een behoorlijk php-script toch al gauw 3-5MB per thread zijn) die hij moet draaien, al die threads zijn meestal aan het wachten tot de clients "klaar" zijn. Dan kunnen ze gesloten worden of een volgende client helpen, maar zolang die threads open staan nemen ze wel ~4mb geheugen in. En moet er wel meer gecontext-switched etc worden
Als die verbindinkjes allemaal net ietsje sneller dichtgaan scheelt dat wel degelijk in de cpu-load, maar of dat verschil helemaal teniet gedaan wordt door de compressie hangt natuurlijk weer af van de mate van compressie, ik vermoed dat level9 ietsje te veel van het goeie is (compres maar een tekst bestand met gzip op level 1 t/m 9 om te kijken hoeveel verschil er zit) aangezien level9 meestal niet vreselijk veel meer toevoegd tov de iets lagere, maar vooral meer cpu vraagt.

Humm, volgende keer eerst maar es kijken hoeveel pagina's zo'n topic is

[Verwijderd]

Euh

Dit compressie gedoe klinkt fantastisch, maar zijn er ook voorbeelden hoe je het met ASP zou kunnen doen??

[Norjee]

In ASP zal het vast wel kunnen

Kijk maar eens naar het scriptje (een van de eerste links in dit topic) dat het bij php doet

Is heel simpel
-Alle output opvangen
-browser check voor onderstreuning
-header maken dat browser gecompressed data krijgt
-uitvoer / html of php
-opgevangen output gzippen en outputten

[tomato]

Kijk eens in de post van 17 nov 08:27 eerder in deze draad van The Lord (check z'n link)...

[Verwijderd]

ok, bedankt jongens!

update: wow.. je kan het gewoon op de server instellen en het gebeurt automatisch =]
thnx !

[chem]

graag gedaan iedereen...

btw, ik heb beetje lopen spieleren, en wat ACM al zei - er zit tussen '6' en '9' compressie alleen maar tijd, en amper extra compressie.. we hebben het over enkele tientallen bytes op 100 kb

maar

ik ga @ bed

toedeloe!

ps. wanneer komt (damned!) die sidebar voor netscape? 't duurt allemaal weer veel te lang

[Olaf van der Spek]

Op zaterdag 18 november 2000 11:00 schreef ACM het volgende:
Wat ik ondertussen wel doorheb is dat een webserver met apache behoorlijk zwaar belast kan worden door al die threads (die met een behoorlijk php-script toch al gauw 3-5MB per thread zijn) die hij moet draaien, al die threads zijn meestal aan het wachten tot de clients "klaar" zijn. Dan kunnen ze gesloten worden of een volgende client helpen, maar zolang die threads open staan nemen ze wel ~4mb geheugen in. En moet er wel meer gecontext-switched etc worden
Als die verbindinkjes allemaal net ietsje sneller dichtgaan scheelt dat wel degelijk in de cpu-load, maar of dat verschil helemaal teniet gedaan wordt door de compressie hangt natuurlijk weer af van de mate van compressie, ik vermoed dat level9 ietsje te veel van het goeie is (compres maar een tekst bestand met gzip op level 1 t/m 9 om te kijken hoeveel verschil er zit) aangezien level9 meestal niet vreselijk veel meer toevoegd tov de iets lagere, maar vooral meer cpu vraagt.

Humm, volgende keer eerst maar es kijken hoeveel pagina's zo'n topic is

Als threads wachten tot de client klaar is, gebruiken ze volgens mij vrijwel geen CPU tijd hoor.
Het zou dus alleen maar schelen voor memory load.

[smoove]

HTTP compressie niks nieuws.
Zit standaard ingebakken in IIS 5

[Hans]

SOMAN! IIS is echt VET!

[chem]

hans> misschien moeten we apache en php maar laten varen en op IIS/ASP overgaan?

dat lijkt me wel de shit



(geintje!)

[Hans]

BWAHAHAHA lachen met jou

[smoove]

geen geintje http compression zit standard in IIS

[Jasper]

Je snapt het niet..

[HenkS]

misschien snap ik ook iets niet, maar als ik dit alles goed lees:

dan duurt het met compressie iets langer voordat een browser begint met het ophalen van een pagina, maar begint ie eenmaal dan is het wel veel sneller??

maar als je dan een pagina met weinig content hebt, dan kun je dus beter geen compressie gebruiken, of wordt het noooit langzamer hierdoor?

[bartvb]

Oooooh, man! DIt is een topic van november vorig jaar.. Pfffffff..

Maar als je weinig content hebt is alles ook zo door gzip heen gehaald dus duurt het bijna niks langer voor er data word verstuurd.

Verder is het zo dat dat comprimeren on the fly gebeurd, er wordt dus al begonnen met verzenden voordat de hele pagina klaar is..

[HenkS]

maar ja, je krijgt dus wel een hogere server load door dit alles, dus goed is het ook niet altijd?

[_JGC_]

Wat ik een beetje vreemd vind:

IE 5 SP2 W2K gaat keurig met zlib om, maar IE5 en IE5.5 op win98 snappen er geen bal van. Dan krigj ik gewoon de normale page. Is dat niet wat vreemd?

[razor-x]

Mhmz beetje vaag z'n topic van vorig jaar opnieuw openen he !

[ACM]

Wazige omhoogschop actie.