4 - 1 compression ratio is fine unless you are serving lots of rich content, which generally will see no performance gain if not reduced performance.
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. <wr...@rowe-clan.net> > 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 www.keenuh.com burgo...@keenuh.com
