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
