On 01 Jun 2010, at 2:30 AM, Bryan McQuade wrote:

I had a conversation with a well known hosting provider recently and
they told me they use the default Apache configuration for their
shared hosting service. When I asked if they provide gzip as an option
for their users, they said no, since it was not enabled by default.
When I explained to them that enabling gzip has significant benefits
for end users they were very interested in turning on gzip. This
company just used the default Apache config, assuming that it was
reasonably well tuned by default. You can claim that they're making
bad, uninformed decisions, or whatever you want to, but the fact
remains: some Apache users assume that the default config is a
reasonably good config, and use it as-is.

The very definition of "tuned" means "tailored for your local setup".

The default httpd configuration works reasonably well out the box. It is only when your site has special needs that it should start changing the setup, and the site should understand what their needs are and whether it is appropriate to turn it on.

Zooming into mod_deflate, mod_deflate only makes sense if you have the CPU to support it. If you don't have enough CPU support (think virtualised hosts), mod_deflate will be a performance drag, not a boost. Typically, you would want to front a mod_deflate with an HTTP cache, such as mod_cache (or equivalent). Here mod_cache only makes sense if you have the disk space to support it, and there is no real one-size-fits-all cache setup.

The next problem is that you only want to enable mod_deflate on compressible content - that means "not images" for most people, but might not be. Again, not every site has the same content, and therefore not every site has the same setup for mod_delate.

This said, our default config is 15 years old, and attempts to disable deflate for browsers that don't support it, like "Netscape 4". Unless there are modern browsers that have broken protocol support for transfer encoding, these obsolete examples need to be removed.

Regards,
Graham
--

Reply via email to