httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: mod_cache: store_body() bites off more than it can chew
Date Mon, 06 Sep 2010 13:22:23 GMT
On 06 Sep 2010, at 3:10 PM, Paul Fee wrote:

> If mod_disk_cache's on disk format is changing, now may be an  
> opportunity to
> investigate some options to improve performance of httpd as a  
> caching proxy.
> Currently headers and data are in separate files.  If they were in a  
> single
> file, the operating system is given more indication that these two  
> items are
> tightly coupled.  For example, when the headers are read in, the O/S  
> can
> readahead and buffer part of the body.
> A difficulty with this could be refreshing the headers after a  
> response to a
> conditional GET.  If the headers are at the start of the file and they
> change size, then they may overwrite the start of the existing  
> body.  You
> could leave room for expansion (risks wasted space and may not be  
> enough) or
> you could put the headers at the end of the file (may not benefit from
> readahead).

This requirement is the reason the files are separate now. It's not  
that practical to have a header which can change size in time, and a  
body which can change size in time in the same file.

> On a similar theme, would filesystem extended attributes be suitable  
> for
> storing the headers?  The cache file's contents would be the entity  
> body.  A
> problem with this approach could be portability.  However the APR  
> could
> abstract this, reverting to separate files on platforms/filesystems  
> that
> didn't offer extended attributes.
> I haven't tested extended attributes to see if they offer  
> performance gains
> over separate header and body files.  However it seems cleaner to  
> have both
> parts in one file.  It should also eliminate race conditions where
> headers/body could get out of sync.

mod_cache.h provides a provider mechanism for cache implementations,  
it is entirely possible to create a new cache implementation targeted  
directly at platforms where extended attributes are supported. The  
only requirement would be that it be possible to update the extended  
attributes atomically.


View raw message