httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeffrey E Burgoyne" <>
Subject Re: Fast by default
Date Wed, 02 Jun 2010 10:29:50 GMT
4 - 1 compression ratio is fine unless you are serving lots of rich
content, which generally will see no performance gain if not reduced

As pointed out this option is not a one size fits all arrangement.
Shouldn't the default be the best config for everyone based upon the
lowest common denominator?

> On Tue, Jun 1, 2010 at 9:04 AM, William A. Rowe Jr. <>
> wrote:
> [...]
>> Plus deflate may provide no benefit, and degrade performance, if the CPU
>> utilization is a greater concern than bandwidth utilization.
> The CPU utilization is an interesting topic for me because I've been
> working on a related type of transform (minify of dynamic content) and
> I've gotten into the habit of measuring nanoseconds of processing time
> per byte of content.
> With that in mind, I just added in some instrumentation around the
> zlib calls in mod_deflate and found that the compression takes 30-60
> ns/byte for buffers of a few KB. (This is with Apache 2.2.14 and zlib
> 1.2.3 on a 2.8GHz x64 processor.)
> To put that number in perspective, if you were to devote the
> equivalent of one CPU core worth of processing power on a web server
> host to compression, 30ns/byte means the host would be able to do
> real-time compression of ~266Mb/s of outbound traffic.
> Assume that your monthly bandwidth pricing is $10 per 95th percentile
> peak Mbps.  Assume further that by turning on deflate you can reduce
> outbound bandwidth usage by 75% (i.e., you're getting 4:1
> compression).  Thus the CPU core that you've devoted completely to
> deflate processing will save you ~$2000 per month in bandwidth
> pricing.  If the CPU core costs less than $24000 per year (amortized
> capital cost plus power, cooling, support, data center space, marginal
> cost of additional sysadmins needed to support each additional server,
> etc, etc), then you still come out ahead by turning on deflate.
> A few additional thoughts:
> 1. Speeding up the deflate implementation would be an unqualified win.
>  Supposedly the recently-released zlib 1.2.5 is faster, but I don't
> have any data on it.
> 2. The best practice I've found for implementing compression in a web
> server is to do the compression in the server closest to the network
> edge.  E.g., if you have a web server fronted by a proxy cache, do the
> compression dynamically in the proxy cache rather than the web server.
>  That way the cache doesn't have to store multiple variants of each
> object.  Similarly, if you're using a CDN for content that can benefit
> from gzip, ask your CDN if they can do conditional compression for
> non-problematic user-agents on-the-fly.
> -Brian

Jeffrey Burgoyne
Chief Technology Officer
KCSI Keenuh Consulting Services Inc

View raw message