httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: some reasons why Apache 2.0 threaded is slower than prefork
Date Thu, 01 Mar 2001 19:26:18 GMT
Find it here...

This code has some horrible hacks. I was just trying to put something together
to do some benchmark testing with.

Here is the idea behind the allocator...
Define 10 queues (or lists) of free blocks.  There is a list of 32 byte
blocks, a list of 64 byte blocks, a list of 128 byte blocks, ... up to 8192.
If you apr_malloc(30), you will pull a block off the 32 byte block list and
use it. If you need 33 bytes (apr_malloc(33)), you would pull a block off the
64 byte block. When you free a block, there is a field in the block header
telling you which list the block needs to be returned to.  Pretty simple. If
you play with this, make sure you call apr_mem_init() somewhere early in the
MPM (or in the apr_init).

If we were to develop this idea, I would like to add guard bands around each
block to check for memory overwrites, etc. in debug mode. Enable list size to
grow and shrink. Now, I malloc 8192 bytes for each list then carve it up into
pieces and if a list runs out of freeblocks, I revert to malloc/free.  Perhaps
enable allocating out of shared memory (for process MPMs). Use more efficient
mechanisms to sync access to the lists.


----- Original Message -----
From: Cliff Woolley <>
To: <>
Sent: Thursday, March 01, 2001 1:46 PM
Subject: Re: some reasons why Apache 2.0 threaded is slower than prefork

> On Thu, 1 Mar 2001, Bill Stoddard wrote:
> > FWIW, last week I wrote a very simple memory allocator (apr_malloc(),
> > apr_calloc(), apr_free()) and replaced all the malloc/calloc/free calls in
> > apr-util/buckets with the apr_* calls.  It was good for a 10% performance
> > boost serving static pages on Windows. My allocator used intraprocess apr
> > mutexs which are implemented as Win32 CriticalSections. There are probably
> > better sync objects available (compare and swap) which would be good fora
> > more %.
> >
> > If anyone is interested, I'd be happy to post it to the list in all it's
> > unfinished/unrefined glory.
> Sounds very interesting... I'd like to take a look at it.
> Thanks,
> Cliff

View raw message