Ruediger Pluem wrote:
That sounds good, but thats more about the parts I haven't checked so far. Sorry for nit picking on this, but you said that your patch will save disk reads and syscalls and I still do not see this.
true. a header file almost always fits into the buffer of apr_file_t, so only one syscall.
As said, for the cycle saving aspect I need time to check for further comments.
BTW, on my opteron test boxen, this speeds up mod_disk_cache by 10% -- maybe the different/better memory architecture of the opterons?
Through this, and some other "minor" patches, I have been able to get mod_cache/mod_disk_cache within 10% of our homegrown cache. That's close enough to make us consider using the "stock" modules. However, there are a couple of features we would need:
-override vary headers. I submitted a patch some time ago that used env to do this. I can re-submit -a way to set max/min cache time that will override the expires header. Mostly just need max. probably not too hard. -better "cache" management. an idea: be able to register functions/provider that gets called every time something is stored/removed from the cache. This would allow developers to write cache purgers easily. needs to be able to handle the vary info (ie, purge all versions of /xxx.html) -set mix/max/default expire per CacheEnable rule (maybe useful for other options as well)
-getting the other 10% of performance would be cool too :) Thoughts? -- Brian Akins Lead Systems Engineer CNN Internet Technologies
