Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 5915 invoked by uid 6000); 13 Oct 1999 16:50:15 -0000 Received: (qmail 5909 invoked from network); 13 Oct 1999 16:50:13 -0000 Received: from imo13.mx.aol.com (198.81.17.3) by taz.hyperreal.org with SMTP; 13 Oct 1999 16:50:13 -0000 Received: from TOKILEY@aol.com by imo13.mx.aol.com (mail_out_v23.6.) id gLCSa11018 (3975) for ; Wed, 13 Oct 1999 12:49:43 -0400 (EDT) From: TOKILEY@aol.com Message-ID: <0.b35c2d40.25361226@aol.com> Date: Wed, 13 Oct 1999 12:49:42 EDT Subject: Re: Apache 164 percent speed increase To: new-httpd@apache.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: AOL 3.0 16-bit for Windows sub 86 Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org In a message dated 99-10-13 09:57:45 EDT, you write: > I also agree that real-time compression on the server side > is a misunderstanding. Compression slows down CPU, and response time... Prove it. If the TCP/IP subsytem has 80 percent less work to do... you don't see that as 'gaining' an appreciable amount of CPU time? If the argument is simply 'who is a bigger drain on the CPU... a compressor or the TCP/IP susbsytem...' Then it's time the rubber met the road and some proof gets out. Our tests show that simply 'assuming' that properly written compression algorithms are no match for simply sending thousands of needless bytes is an absolute fallacy. Kevin Kiley CTO, Remote Communications, Inc. http://www.RemoteCommuncations.com RCTPDS real-time online document compression server. http://www.rctp.com