httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <>
Subject Re: Fast by default
Date Wed, 02 Jun 2010 05:27:54 GMT
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.


View raw message