Why doesn't WW use GZIP compression

4X faster page loads and lttle CPU penality

[bumpski]

Why doesn't WW support GZIP compression?

If WW (Webmasterworld) supported just Level 1 GZIP compression on its servers, 56K modem users would have 4 times faster page loads. The webmasterworld servers communications load would be cut by a factor of 4. System CPU usage would drop, while application CPU usage would increase. At level one GZIP compression the savings due to reduced bytes to handle, far fewer context switches per message, etc, would balance with application CPU usage increase. It seems like a win win.

Vastly better performance for end users!

[amznVibe]

That results in machines wasting CPU cycles trying to compress something that is now already compressed. In fact, the machines you most imagine will benefit from the compression (dial-ups) are the most likely to already have hard-wired compression running in the conversation.

If you have your own server or even just a page with PHP, try the gzip function or mod_gzip yourself - forget theories without realworld trials. Whatever connection you use gzip on the server side will always be faster. Anyone who tries this will instantly understand why it's a no-brainer. Forget all the theories about dialup modems doing 4:1 compression etc. Sending one fourth the data in the first place is always faster than the host isp modem re-compressing it. v42bis compression steps out of the way when it sees pre-compressed data anyway.

The only worthy argument against is FBIB and I think it's mute anyway with the right configuration. The more text on a page the more valuable gzip is and it's *extremely* valuable for any forum.

[instinct]

On a related note, seems there is no external CSS file for WebmasterWorld. And there's a heck of a lot of font tags in that there html source. If page load times were a huge concern thats definitely where I'd start.

I'm sure there's a good reason for it though. Maybe a wholesale change to external CSS for WebmasterWorld would disrupt WebmasterWorld's excellent G rankings? Is there another possible reason?

[amznVibe]

Ha, don't even go there (on CSS and external stylesheets).
Brett doesn't believe in anything invented after 1996
including CSS, external javascript, internal forum searches and gzip html compression...
XML was invented in 1997 and RSS in 1999 so that kinda sticks out around here.
;)

[badtzmaru]

Brett, before you make the mod_perl mistake, take a look at FastCGI. Mod_perl is archaic, shoehorned technology that few save the core development team fully understand. A few months back, I was talking to a lead web developer for one of the big 3 television networks concerning the memory bloat issues they were experiencing with mod_perl. I asked the same question I always mod_perl users: "You realize that memory freed from the perl application is not released back to the operating system, right? Do you understand that, during the lifespan of the apache child, memory utilization will always be at least that of the largest allocation ever performed?".

A better solution than mod_perl is FastCGI. FastCGI forks your perl web apps as daemons (outside of apache), preforking if necessary, and them intercepts the IO and redirects it to a small apache module. It will dynamically adjust the waiting process pool based on utilization and can kill off processes that grow too large after they finish their current request. The process pool can exist on multiple machines, if necessary. The "application server"-ish paradigm ensures that the number of potentially memory-intensive processes are minimized and that a thin apache can be used to serve content.

[bumpski]

Interesting, the topic disappeared from the highlighted topics thread prematurely, usually those topics just trickle down the page. Makes an interesting statement. (I'm not sure what though). Since it did disappear, I had to double check, but no GZIP. Still very good performance for broadband.

But wow look at the Adsense forum, almost 10X compression if GZIPped.

http://www.webmasterworld.com/forum89/ is not gziped. If it were gziped the requested page (42832 bytes) would be the following sizes at:
Level bytes % of orig size 1k/sec 3.5k/sec 10k/sec 100k/sec utime
0 42848 100.0374 41.8 12 4.2 0.4 0
1 5307 12.3903 5.2 1.5 0.5 0.1 0

Again Webmasterworld is greatly appreciated, I'm sure, by all who posted here.

I found it an interesting discussion with quite a few useful suggestions, with some ads (useful as well) thrown in! Time to put it to rest.

[Namaste]

Brett, I am very interested in what PaulRobers3000 says "Gzip chunks". Have you tried this? I would love to implement this.

On a seperate note how are you measuring this:

" the mass majority of this audience is on high speed net connections. We run about 80% on dsl/cable or other high speed. We even have about 10% on t1's or higher here. "

[Brett_Tabke]

Very interesting discussion. I tried a little testing last night when under light load and we went about 22 mins before the server locked. Which is the longest it has ever went with gzip - that is promising for the future.

> We run about 80% on dsl/cable or other high speed.

some mods really let me have it on that stat. That stat is "page views" and *not* uniques. Which uniques are about 60% cable/dsl/faster. That means cable users abuse things at a higher rate... ;)

badtzmaru - thanks for the tip on mod perl - I might just try it though on a couple of mission critical programs.

[trillianjedi]

we went about 22 mins before the server locked

Why would the server lock? Out of RAM?

When you were testing, what was the "percieved" speed difference, putting yourself in the shoes of a user?

TJ

[Brett_Tabke]

> Why would the server lock? Out of RAM?

Out of "everything" (cpu & ram)... box is 2.8m intel with 2gig ram redhat.

> percieved

There is a noticeable 5 second delay before anything shows in the brower. At that point it appears people start hitting reload because they think the page has stalled (which causes more server load and more people to press reload). That 5 second delays continues to grow as the server slowly fades away under the load.

[trillianjedi]

Thanks Brett - handy info.

Good thread.

TJ

[Angelis]

Any chance someone can give a more in depth piece of information into how to turn / use GZip?

Newbies amongst us are looking puzzled at this point...!

[zoltan]

I experienced the same 4-5 second delay, but only on the homepage. Every other page seems to load a lot faster. I mean a lot more faster.
Strange thing is that the homepage without gzip is starting to load instantly.
Any comment here?

[Namaste]

I'm surprised that the reported delay is high as 5 seconds. On my own website, it is about a second longer. We brought this down through lots of optimizations.

Ofcourse it's not a fair comparison, because we are running of multiple boxes and also are a image heavy site.