This project is a spin-off of the issue:

ChainedFastBackend should not invalidate the whole fastBackend when doing a Set()

Expected performance improvement is about -50% less database queries when "things change" and -30% wall time, results being better the more cache tags and complex the application is.

What is the expected reduced load on the database?

Log in and create 2 articles with base install: ~2000 database statements executed

The same thing with Wincache, Couchbase and Supercache enabled: ~ 250 queries

See the demonstration video:

How does this work?

- Introduces a new, simpler, sleeker and faster cache layer that does not support cache tags. Includes default implementations for APC and Database, and the Wincache and Couchbase modules already include implementations of them.

- Replaces the default ChainedFastBackend implementation for one that keeps cache tags in the fast backend, but coordinates invalidations between webheads.

- Replaces the default cache tag checksum invalidator service for one that uses chained raw fast storage cache to store caches in APC/Wincache backed by a shared and persistent cache backend.

- A key value store implementation that let's you use any cache backend on top of the database storage. Only makes sense to use it if you are also using Couchbase, Redis or Memcache. The Couchbase module is already leveraging this.

Project information