httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Fee <>
Subject Re: mod_cache: store_body() bites off more than it can chew
Date Mon, 06 Sep 2010 13:10:04 GMT
Graham Leggett wrote:
> Given that the make-cache-writes-atomic problem requires a change to
> the data format, it may be useful to look at this now, before v2.4 is
> baked, which will happen soon.
> How much of a performance boost is the use-null-terminated-strings?
> Regards,
> Graham
> --

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 

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.


View raw message