Experimental project

This is a sandbox project, which contains experimental code for developer use only.

No code here yet, just notes for now

This project will implement cache chaining for D7.

I have wanted this for ages. Subsequently found out about #365088: Implement a hierarchical (primary / secondary) engine which has some code but is stalled. Apparently http://drupal.org/project/cache has something like this, but I've not reviewed code yet. Have a very specific idea how I want this to work, so will likely work on that here, then review cache project to see how it compares. Neither cacherouter nor cache have 7.x branches, this could end up being the 'port', or maybe it should be a new project.

Requirements

The main use case for this is a site with at least two web servers. Drupal 7 has the cache_bootstrap bin, which is used for a relatively small number of cache items, that shouldn't be updated too frequently, and are often quite large (variables, system_list etc.).

The plan is to have this bin cached in APC (or file caching on shm) on each local webserver. Some sites do this already, but this leaves you with cache coherency issues, and means that each web server needs to build it's own cache item.

Instead of this, we'd keep the local cache storage, but have a second layer underneath it - most likely memcache.

There are two primary things this needs to do:

1. Keep a tombstone record (per-bin), that is updated on writes/deletes to the bin. This will be used to validate whether caches can be pulled locally or not. An alternative is much shorter TTLs on the local records. All caching backends that are consistent (i.e. over the network), should provide the ability to get and set a tombstone, caching backends that aren't we should allow the administrator to choose between tombstone and short TTL per bin.

2. If caches are empty or outdated, allow a fall through to the second layer of caching and pull from there. This means that if using the memcache project's stampede protection, you could ensure that only one server is building cache items at any one time. Even if not there's a chance that cache misses can pull from memcache instead of needing to do their own rebuild anyway.

There are other potential things we might want - some caching backends like the database or redis are persistent, this would allow chaining memcache + database for {cache_form} for example.

Also it's not inconceivable you might want more than two caching backends for a bin (can't think why), don't necessarily need to support this but should leave it open.

Drupal 7 cache backends are classes. It is likely we'll need to implement tombstone support in the cache backends themselves, but that can be done by extending the classes already provided and/or submitting patches - no need to fork.

Project information

  • Created by catch on , updated