Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 5064 invoked by uid 500); 17 Jan 2001 00:33:37 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 5041 invoked from network); 17 Jan 2001 00:33:36 -0000 Date: Mon, 15 Jan 2001 16:43:35 -0800 (PST) From: rbb@covalent.net X-Sender: rbb@koj To: "new-httpd@apache.org" Subject: Re: Bucket/brigade re-use pool. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > > > The previously discussed re-use pool for buckets/brigades was the next thing > > > that I was going to work on (before the code freeze came up). Does this count > > > as frozen development, or is this something I can work on? > > > > We are in code freeze. This is not a bug, it is an optimization. Feel > > free to work on it, but it will not be committed until after the > > beta. This patch takes a real chance of de-stabilizing the server, which > > is what we are trying to avoid. The goal here is to get the server to the > > point that we can get to beta. > > performance problems *are* bugs. the server *is* destablised right now, > it chews lots of memory, it's slow, it generates crap small packets on the > wire, there's no guarantee that it'll even match 1.3 performance. (and > that's pretty pathetic considering how poor 1.3's performance is.) > > it really irks me to see optimisation relegated to the final days in the > hopes that nothing was screwed up so seriously that a performance wiz > can't figure out some way around it without changing the API. Understand Dean, we aren't saying that the API couldn't be changed to work better, but people in the group have veto'ed changing the ap_r* API's. This severly ties our hands when it comes to making those functions work well with the buckets. Also, the change that Paul is talking about is just going to keep us from malloc'ing and free'ing buckets, just to create new ones. Yes this is a simple optimization that will improve our performance a bit. It is also not something that will require an API change, and it isn't something that must be done before the beta. I am much more interested in finding a few more seg faults, than in potentially introducing new ones right now. Ryan _______________________________________________________________________________ Ryan Bloom rbb@apache.org 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------