Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <40EC3758.8030807@web.turner.com>
Date: Wed, 07 Jul 2004 13:48:08 -0400
From: Brian Akins <bakins@web.turner.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.7) Gecko/20040702 Debian/1.7-3
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: Some Oprofile results
References: <s0ea9a90.099@sinclair.provo.novell.com>
 <40EBEAAC.4040609@web.turner.com> <40EC10C1.9090804@wstoddard.com>
In-Reply-To: <40EC10C1.9090804@wstoddard.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Bill Stoddard wrote:

>
> I'd certainly be interested in knowing how much faster mod_url_cache 
> is as compared to mod_cache/mod_mem_cache. The only way I can see to 
> -dramatically- improve the performance of mod_cache/mod_mem_cache is 
> to completely bypass i/o filters. I have some patches to mod_mem_cache 
> laying around that give perhaps a 10% performance improvement by 
> prebuilding headers and aligning them on cache boundaries, but 10% is 
> not really that great.
>
Like I said, it can fill up two Gig pipes on a dual Opteron with ~25% 
idle time. mod_cache can't fill up one.

If you run in quick_handler, the only way you get filters (other than 
core_ouput) is if you add them your self.  Guess if I did or not :)

If the headers are stored and "thawed" in an efficient manner (both 
processor and memory) they don't affect the performance much.  Also, 
sometimes mmap is slower than just plain old read.

Also, using a filesystem and sendfile is much faster than serving from 
RAM, plus multiple processes can "share" the same cache.  mod_cache 
doesn't do that.

All of these are based on my observartions of our environment. 

-- 
Brian Akins
Senior Systems Engineer
CNN Internet Technologies