httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Re: Apache 164 percent speed increase
Date Wed, 13 Oct 1999 02:21:57 GMT

Hi tani...
This is Kevin Kiley...

In a message dated 99-10-13 01:51:05 EDT, tani hosokawa writes.

>  I also doubt that there's no way a server that's spending that much
>  time on compression is going to be able to compete against a 
>  normal Apache that's handling
>  real traffic (300+ requests/sec, 10k average request?).  OTOH, I'd love to

Wanna make a bet?

This is the fallacy that has been laying on the table for some time.

Our servers and our testing have proven that it is just that...
a fallacy. Properly written compression code which reduces the
number of output bytes which must then be transferred to the 
lower level TCP/IP transmission code does nothing but INCREASE
the CPU's ability to do things FASTER.

Are you following me? Everyone who coins that argument is
fogetting something. Pie is never free. Either you spend a 
LITTLE time reducing the content up to 80 percent and then
your TCP/IP sub-system has that much LESS to do... or you
sit back and worry that compressing will be slow and you just
keep stuffing huge amounts of needless data down the 
TCP/IP susbsytems throat where it has to spin and spin and
spin trying to send all the damn data you've given it.

Our products and our testing shows that spending the time
to decrease the number of bytes being handled by the TCP/IP
subsystem INCREASES the chances of achieving a higher
TPS ( Tranaction per second ) rating.

That is worth repeating...

Spending the time to compress the data up to 80 percent
does nothing but INCREASE your chances of achieving 
a higher TPS rate because the TCP/IP sub-system has
that much 'less to do'.

Kevin Kiley
CTO, Remote Communcations.com
http://www.RemoteCommunications.com
RCTPDS online real-time document compression server...
http://www.rctp.com


> Subj:  Re: Apache 164 percent speed increase
>  Date:    99-10-13 01:51:05 EDT
>  From:    unknown@riverstyx.net (Tani Hosokawa)
>  Sender:  new-httpd-owner@apache.org
>  Reply-to:    new-httpd@apache.org
>  To:  new-httpd@apache.org
>  
>  On Wed, 13 Oct 1999, Manoj Kasichainula wrote:
>  
>  > On Tue, Oct 12, 1999 at 11:34:38PM -0600, Peter J. Cranstone wrote:
>  > > 10 transactions per second was your 'laugh test'.... 10 transactions 
per
>  > > second of a 10,495 byte  document over a dial up modem is IMPOSSIBLE. 
> That's
>  > > 1,049,500 ( 1 MILLION plus ) BYTES PER SECOND!
>  > 
>  > 10,495 * 10 = 104,950.
>  
>  I assume he's talking about bits.  800kpbs is nice.  Still, here's
>  something interesting about this:  I've got a crappy little cable modem
>  here, and when I download music.htm.gz from the demo page I get it at
>  about 4k/sec, but when I download the uncompressed version I download at
>  35k/sec.  Nice that it's going to get to me quicker, but I bet that CPU is
>  churning at 100% to get it to me (much slower than normal).  I also doubt
>  that there's no way a server that's spending that much time on compression
>  is going to be able to compete against a normal Apache that's handling
>  real traffic (300+ requests/sec, 10k average request?).  OTOH, I'd love to
>  try it, and I'd be willing to use my traffic to test that theory...
>  
>  ---
>  tani hosokawa
>  river styx internet

Mime
View raw message