To get mod_cache/mod_mem_cache (I know little or nothing about mod_disk_cache) really performing competatively against best-of-breed caches will require bypassing output filters (and prebuilding headers) and possibly bypassing or at least reworking input filters. And the
*nod* However, due to the filter design, it should be easy to move it around. The catch with bypassing the protocol filters is that we have to be really smart about the Vary headers and such.
prebuilt headers will need to be properly aligned in memory. You remember the patch I posted to the list, gee, maybe up to 2 years ago now to reimplement some aspects of how data was read into input filters? Dipping into the input stream to read one line at a time turns out to be a fairly significant bottleneck serving cached content. That patch improved performance servibg cached content by 5 maybe 10% if I recall correctly.
Is that just for proxies? Not sure that reading input would be such a bottleneck here. So far, I haven't seen anything to indicate it is.
I also seem to recall mod_cache/mod_mem_cache making a couple of gratuitous calls to apr_time() which can be rather expensive on some platforms. Maybe that has changed since last time i looked at it.
The only similar thing I saw was the ap_set_last_modified(). The explode code path had to call down to gmtime which was ridiculously expensive. (About 1-2% of the overall time was down in gmtime.) -- justin
