httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter J. Cranstone" <>
Subject RE: Apache 164 percent speed increase
Date Wed, 13 Oct 1999 14:29:13 GMT

No you are not a........

A) gzip compression is supported by client browsers because someone did
think that it was a good idea to compress data one day.

B) I would believe that the compression of gzip uses much more CPU time than
the compression that is built into the hardware of your modem.

Let me make it clear that we all understand that "pie is not free in this
universe". The actual compression cycle is going to require just that,
cycles. But we need to look at this further... the average file (HTML) on
the web probably weighs in at about 50K or more, but less than 100K.
Depending on HOW you code you compression program you should be able to
compress this size file in about a millisecond or so. The compression cycle
is now over. What you have to do next is get it to the user which is the job
of the server. Considering it's 70% smaller this is going to take a fraction
of the time required by the uncompressed file... we're no longer taking
milliseconds here, were talking SECONDS... during those seconds the server
is using cycles to send the data through the tcp/ip sub layer.

We've spent over a year working on this program. The first versions caused
the very problems that everyone on this forum is talking about, it CRUSHED
the server. Apache is a forking server and requires it's own memory
resources for each new child process which is spawned. Spawning and
compression is combustible combination and resulted in such poor performance
that we shelved the approach.

As Warner Von Braun is quoted as saying "You can usually recover from
production flaws but you can never fully recover from a bad design." We had
a bad design and that's all there was too it. We went back to the drawing
board and now we have a new design which gives us the stats you've seen on
our site. Apache is free to do it's work and we handle the "bits" coming
into and leaving the server.

Final point on hardware compression in your modem. Most of the time the
modem is spent receiving data, i.e. you make a get request which sends out a
small packet of data for the web server to process, the HTML pages are then
returned to your PC in packets. The modems are not smart enough, yet, to
know what type of data it is, or whether or not it can be compressed..

Remember we don't compress data sent from a users PC to GET a web page, we
only compress the returning data, the modem has no idea what is coming back
into the PC. Decompression whilst it consumes cycles is ALWAYS faster than
compression (entropy encoding scheme discussed here) we've moved the
decompression stage to the clients PC which even if it's 386 is very fast,
especially on a small page.


Peter J. Cranstone

-----Original Message-----
From: []On
Behalf Of Jeff Johnson
Sent: Wednesday, October 13, 1999 8:07 AM
To: Peter J. Cranstone
Subject: Re: Apache 164 percent speed increase

On Tue, Oct 12, 1999 at 11:34:38PM -0600, Peter J. Cranstone wrote:
> Anyway, as you can see we actually more than DOUBLE the number of
> transactions per second using compression. 21 transactions per second
> to 56 or a 166% improvement. "The assertion about saving modem users
> bandwidth is ludicrous". What is ludicrous is that statement. I'm going to
> let you do the math. It's very simple.

Not to intrude on this conversation, however, I see two points here:

a) gzip compression of pages, if supported seamlessly by clients is
   both something that should be supported by HTTP and by Apache,
   because it is a Good Idea (tm).

b) However, is the server actually free the handle more requests?
   I would believe that the compression of gzip uses much more
   CPU time than the compression that is built into the hardware
   of your modem.  Doesn't the modem try to compress the data again
   as well?  Because of this, you'll always get a 'higher' throughput
   rating when transferring, say, a text file when compared to a .ZIP file.

   We all learned this in our BBS days.  While the data may get to the
   "166% faster", with the extra CPU overhead, I seriously doubt that you
   would be able to process 166% more ACTUAL REQUESTS by enabling gzip

Am I a total moron here?

Jeffrey H. Johnson,
The Web Site Factory,

View raw message