store gzipped cache pages [#8509]

Drupal has a rather efficient page cache for anonymous users. Also, there exist mod_gzip a module for Apache which will send the data compressed which saves bandwidth. however, mod_gzip will compress each served cache page anew. Since we generate the page cache in Drupal it is easy to also compress it and store it that way. Benchmarks indicate that a performance increase of about 13% can be achieved.

Further improvements could come from the fact that the cache table will be smaller and thus selects should be faster. My cache table was almost empty.

I still need to investigate under which circumstances gzencode uses the deflate or the zlib algorithm.

The docs seem to indicate that it would be gzip, but on my servers it is deflate. I wasn't successfull on finding anything on google so any insight any of you has to share would be appreciated.

This is important when inflating the cache again for old browsers that cannot handle gzipped pages (a very small minority of today's requests).

The attached patch has been well tested and not caused any trouble.

Comment	File	Size	Author
#6	gzipped-cache_0.patch	4.39 KB	killes@www.drop.org
#6
#2	gzipped-cache.patch	1.44 KB	killes@www.drop.org
#2
	txt00005.txt	1.07 KB	killes@www.drop.org

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

killes@www.drop.org CreditAttribution: killes@www.drop.org commented 7 July 2004 at 09:34

That's a patch, actually.

Comment #2

killes@www.drop.org CreditAttribution: killes@www.drop.org commented 7 July 2004 at 10:20

File	Size
gzipped-cache.patch	1.44 KB

Updated to apply to CVS, changed a bit after consultation with Steven.

Comment #3

Dries CreditAttribution: Dries commented 7 July 2004 at 22:36

What happens when Apache itself does gzip compression as well? Wouldn't that be a waste of resources?
The fact pages are potentially gzipped ought to be documented in the help text.
I'd also like to see the cache_set() line broken apart in multiple lines using regular if-else constructs.

Comment #4

killes@www.drop.org CreditAttribution: killes@www.drop.org commented 7 July 2004 at 23:14

1) Apache should detect that the output has been compressed already (we set the right header). If it doesn't it is broken.

2) True. To which help text should I add this? Also, this needs a database update:

delete from cache;

3) done.

Comment #5

Dries CreditAttribution: Dries commented 8 July 2004 at 07:25

There is a section about Drupal's cache system in the system module's help. I suggest adding it there.

Some more thoughts:

Should images/files be compressed? I'm afraid some of them end up in the cache too -- or at least, they used to. Maybe that's something we should fix first?
I vagelue remember some applications send a 32-bit CRC as well. It might only be for gzip compression, not for zlib compression.
Can PHP's "ob_gzhandler" be used?

Comment #6

killes@www.drop.org CreditAttribution: killes@www.drop.org commented 8 July 2004 at 19:05

File	Size
gzipped-cache_0.patch	4.39 KB

Here is an updated patch that includes helptext and update.inc. info. the other problems mentioned by Dries were probably solved long ago.

Comment #7

Dries CreditAttribution: Dries commented 8 July 2004 at 19:22

Committed to HEAD.

Comment #8

(not verified) CreditAttribution: commented 22 July 2004 at 20:20

Comment #9

el777 CreditAttribution: el777 commented 5 April 2006 at 09:19

Version:		» 4.6.5
Status:	Closed (fixed)	» Active

I found one bad bug when storing cached pages and working with mod_deflate.

My server: Apache/2.0.55 + PHP 5.1.2 as FastCGI
If cache and mod_deflate are enabled then anonymous pages are incorrect and cannot be showed to user. I tried to debug it with Fiddler - it showed length is transmitted incorrectly. I think it's due to the Apache attempt to compress already compressed page. So header Content-Length becomes incorrect. Of cource double-compressed page cannot be showed well.

Now I have to disable deflate for drupal-based site.