Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 84120 invoked by uid 500); 2 Mar 2002 04:22:45 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 84103 invoked from network); 2 Mar 2002 04:22:44 -0000 Date: Fri, 1 Mar 2002 20:22:53 -0800 From: "'Justin Erenkrantz'" To: Emery Berger Cc: "'Brian Pane'" , dev@apr.apache.org Subject: Re: pools + ap_pfree Message-ID: <20020302042253.GG24710@ebuilt.com> References: <20020301063042.GJ15423@ebuilt.com> <001801c1c1a1$6ba9cc70$ef801942@ristretto> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001801c1c1a1$6ba9cc70$ef801942@ristretto> User-Agent: Mutt/1.5.0i X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, Mar 01, 2002 at 10:19:17PM -0600, Emery Berger wrote: > High-performance was indeed one of my design goals. What tests would you > consider authoritative? I've been using static page loads, driven by a > process on the same machine. This was the best way I found to really > stress pool allocation. I'd be happy to run any other tests you could > recommend. I believe that we found that mod_include (multiple #includes) or mod_autoindex request (lots of subreqs) really stress the pool code. I think Brian had one test case where ~30 pools were created and destroyed during that one mod_include'd request. -- justin