working APC cache module

I went through the cache override module carefully, and basically I've rewritten it. I stripped out those features which were not implemented (such as statistics), fixed the issues related to cache flushing, and avoided the lookup index for cache_get calls. I also killed all the logging, because it wasn't telling me much and my agenda here is to save database calls.

I may have also made decisions that are completely wrong. Instead of relying on Drupal to flush the cache, I use APC's time-to-live setting when doing cache_set with an expire value. It's only possible to have CACHE_PERMANENT or a cache lifetime. Any data cached with CACHE_TEMPORARY is stored with the site's cache_lifetime variable as the APC TTL. I'll try to look for cases when this matters, but it seems that the only time CACHE_TEMPORARY is used in a cache_set call in Drupal core is at page_set_cache, so it would affect anonymous users who can create or edit nodes and comments. They'd see stale data, which is probably not so hot if they expect to see their changes.

The apc user cache keys are generated from a MD5 hash of the apc_key_prefix, table and cid. This saves a few lines of code and there's very low risk of collision. It might be safer to add some checks into the data, but I think the chances of a problem are in the same range as the chance that new life would evolve in a peanut butter jar on the supermarket shelf.

I do use an index (named with the apc_key_prefix variable) to allow cache_clear_all calls to work. It could get quite large, and I wonder if it's even needed at all. Cache ID seems to be unique across cache tables.

It should be possible to use this on a multi-site installation.

I'm not confident that my work is super fantastic and bug-free, but I've been using it today on a site I'm developing and I see no problems so far. There's some sloppy code... some conditions without statements. There's still some work to do on this module, and I have no solid evidence that it brings any performance boost.

Here's the module. I hope someone will check it out and give me some feedback. It's completely different from this project's module, so I don't know if I should submit this as a patch.

I don't advise people to use this patch for APC. It works (it won't break your installation), but I now see that this Drupal cache module depends on the same patch as the memcache cache module does. That's probably a good thing... I'll see how I can revise my work, but for now, people who are expecting a stable solution should look elsewhere.

I'm not working on this cache module anymore, but I might come back to it. I don't know much about memcache, and APC is super easy to install for a one server web site.

in working on this module, i realized how useful it would be to have granular cache control. For example, it would be nice to store drupal variables in memory (APC), filtered content in the database (Drupal core cache), and full pages on disk (like Boost). When you start playing with cache modules, you're really trying to solve problems that may be specific to your site and that might not work on every site. Do you get my drift? It would be really nice if we could use configure the cache modules on particular facets of Drupal, because at some point, it's all very "custom" and a contributed module will always have to be modified to meet someone's needs.

In that same line of thought, I wouldn't want to store entire HTML pages in memory with APC. It just doesn't make sense to do this for sites with 300 MB of pages that are hit every hour. I doubt this actually provides a performance improvement, and it would be more sensible to cache at the web server level in that case.