Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Tue, 20 Dec 2005 12:50:50 +0000
From: Colm MacCarthaigh <colm@stdlib.net>
To: dev@httpd.apache.org
Subject: RFC: up-front memory allocation
Message-ID: <20051220125050.GA22919@dochas.stdlib.net>
Reply-To: colm@stdlib.net
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.9i


I've been toying with adding some code that allocates a ton of memory to
our connection pool at the start of the connection, to avoid any later
malloc's/mmap's. 

Right now, I've just hard-coded the allocation, and keeping
ap_max_mem_free at APR_ALLOCATOR_MAX_FREE_UNLIMITED and the results look
promising, it certainly improves performance, though I havn't done
detailed performance benchmarks yet.

I'd been considering adding a directive to allow operators to specify an
ammount of memory to allocate pre connection time (in the mpm code),
such that they can avoid any later ones. This directive would require a
fair amount of work on behalf of the operator, which a downside, it's
not very easy to figure out an appropriate value to set it to. Ideally
I'd like more intelligence, like the ability to query all of the loaded
modules what they are likely to need allocated, but this isn't very easy
since we can't predict what modules a connection (which isn't even a
request yet) is likely to touch.

So, is the rough solution something we could add to httpd? or any
thoughts on a more clever approach?

-- 
Colm MacC�rthaigh                        Public Key: colm+pgp@stdlib.net