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
readahead).
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.
http://en.wikipedia.org/wiki/Extended_file_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.
Thanks,
Paul
|