Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 80682 invoked by uid 500); 6 Sep 2001 04:34:54 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 80671 invoked from network); 6 Sep 2001 04:34:54 -0000 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Wed, 5 Sep 2001 21:37:04 -0700 From: Greg Stein To: dev@httpd.apache.org Subject: Re: Add mod_gz to httpd-2.0 ( Thread restart ) Message-ID: <20010905213704.E14040@lyra.org> References: <171.64cdf6.28c814d6@aol.com> <3B96E7F7.100@cnet.com> <20010905200725.E2482@ebuilt.com> <20010905204828.A14040@lyra.org> <3B96F87C.4080206@cnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3B96F87C.4080206@cnet.com>; from ianh@cnet.com on Wed, Sep 05, 2001 at 09:15:56PM -0700 X-URL: http://www.lyra.org/greg/ X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wed, Sep 05, 2001 at 09:15:56PM -0700, Ian Holsman wrote: > Greg Stein wrote: > >>On Wed, Sep 05, 2001 at 08:05:27PM -0700, Ian Holsman wrote: > >>>Some performance results with mod_gz are available at > >>>http://webperf.org/a2/v25/ > >>>(no core dumps.. pages look ok on a real browser while running test) > >>>I'm going to be re-running the tests for a longer period to see if > >>>there are memory leaks (as well as quantify/purify on it next week) > >>> > >>>brief summary: > >>> * numbers are based on pages going through mod-include > >>> * once of the runs looks a bit flaky.. and I'm re-running it > >>> * cpu usage (USR) is VERY high (from 100 without gz to 500) > >>> * page requests down 16% when using GZ > > > > What does this mean? Total bytes transferred? If so, then why only 16% > > > > The number of page requests should be constant, unless mod_gz introduces > > some kind of caching. > > the number of concurrent requests are constant in all of these tests. > we have 50 processes (spread across 10 machines) doing GET's of a page. > when a page is retrived is GET's it again (and again..) > so if the page response is slower, then the pages/second will also be. > > we have a more sophisticated comercial machine which can generate better > traffic, but it is core dumping at the moment so I can run't the tests through it. Ah! By "page requests down..." you mean page requests *per second* ?? You omitted that "per second", so the statistic made no sense... Cheers, -g -- Greg Stein, http://www.lyra.org/