httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <>
Subject Re: Some Oprofile results
Date Wed, 07 Jul 2004 21:55:39 GMT
Brian Akins wrote:

> 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.

Thanks, that's what I wanted to know.  I can pretty much guess the implementation (I've done
similar stuff 
before).  mod_mem_cache takes a middle of the road approach; performance is sacrificed to
provide some ability 
to filter i/o. However, it also makes sacrifices in functionality (like access/auth checking)
by using the 
quick_handler to serve pages. Too many compromises for the 'i want full functionality' folks
and too many 
compromises for the 'i want best raw performance' folks.  mod_mem_cache tries to be all things
to all masters 
but ends up falling short by all accounts. I've got two more patches lying around that I may
dust off if i get 
any free time :-)  The first introduces a config directive that enables moving the mod_mem_cache
handler to 
the traditional handler phase (to pick up full access/auth checking and full filter capabilities).
The second 
patch (I call it my 'go fast patch') does some experiments with prebuilding/caching the response
headers and 
bypassing output filtering (in concept not unlike your mod_url_cache I expect).


View raw message