jmtd → log → mod deflate
I was surprised to learn that Debian's apache2 package does not enable
mod_deflate by default. This is the module which implements compression.
Once enabled, I needed to add application/atom+xml to the configuration in
order for it to apply to atom feeds (which are the most consistently fetched
URI on my site generally, although right now the image from my last log post
is in the lead by a huge margin).
I'm not sure how much merit there is in compressing atom feeds. My primary one
is 4.8k in size and compressed to roughly 1.6k at the time of writing. The
difference in time for fetching those two sizes is dwarfed by connection
setup/tear-down and possibly by the CPU time used for compression. I wonder if
mod_deflate caches the compressed copies? Since my feed (and entire site) is
statically generated by ikiwiki, I could generate compressed copies once at
build-time. Perhaps apache2's content negotiation could be configured to serve
these up.
Comments
To answer a couple of questions: (1) mod_deflate doesn't cache anything. But mod_cache does, if you enable it. However, you need to be aware of bugs in ETag handling that may defeat cacheability of compressed pages. (2) If you have pre-existing compressed and uncompressed versions, apache will do the right thing out-of-the-box. RTFM mod_negotiation and multiviews for the gory detail.
Is this thing a wiki I'm editing? If so, do I need to mention I'm http://bahumbug.wordpress.com/?
Some recent versions of Apache 2.2 have a bug in the filter module which causes etags for compressed content to get "-gzip" appended on the outgoing header, and when it get compared to the actual etag value, it doesn't match, preventing 304 responses, which I would consider worse than uncompressed data. However, I do value efficiency, so I use NGINX as a gzip filtering proxy. -- http://www.docunext.com/