Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <4369471D.5090705@apache.org>
Date: Thu, 03 Nov 2005 00:09:17 +0100
From: Ruediger Pluem <rpluem@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: Potential memory leak in /modules/cache/mod_mem_cache.c
References: <dkb9eh$ue$1@sea.gmane.org> <43693392.6050002@apache.org>
 <4369358A.9050306@wstoddard.com> <436940D0.5040708@apache.org>
 <4369439C.2030400@wstoddard.com>
In-Reply-To: <4369439C.2030400@wstoddard.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit


On 11/02/2005 11:54 PM, Bill Stoddard wrote:

[..cut..]

> 
> Yep, you see it correctly. Mod_mem_cache is most interesting to me
> personally as a benchmark toy. It should be possible to extend
> mod_mem_cache to cache headers (rather than rebuilding them for each
> response sent out of the cache), align storage on processor cache-lines
> and other performance tweaks to serve static pages really really fast

But in this case you have the situation that you have to copy the memory
contents between user and kernel space. Just asking: Does this beat
a working sendfile implementation on a system with filled OS buffer cashes?

> (or cache dynamically generated pages until they become stale). You
> should be able to use mod_mem_cache to explore the static page
> performance limits of Apache HTTPD 2.0.

Thanks for the clarification. So I would think the effectiveness
of mod_mem_cache grows with a shrinking number of httpd processes.
That said I guess the windows mpm by default should provide one of the
most effective environments for mod_mem_cache in contrast to prefork on
the other end.

Regards

R�diger