We could coordinate efforts. Look, it's possible to use exactly 1 module performing all site invalidations. Namespice module allows to do that. If we together agree on common Namespice tag naming conventions, we can make exactly one module which will use our tag convention and flush cache for all supported tags. Then, any module could simply use Namespice to store cache and benefit from automatic cache invalidation. So, for example, if there are 10 modules that invalidate cache based on nodeapi update, there's no reason for every one of them implement that hook_nodeapi().
I already use tags of form "node$nid" in Advanced Panels Cache. This is how I flush cache for all cache entries ralated to node:

function ap_cache_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
  switch ($op) {
    case 'update':
    case 'delete':
      // Clear cache entries tagged with "node$nid" tag.
      $table = ap_cache_content_table();
      $serial_table = ap_cache_serial_table();
      $tags = array('node' . $node->nid);
      ns_cache_clear_all('*', $table, $tags, $serial_table);
  }
}

Great thing here, is that I don't really care where that node is used; I don't even care if it's cached anywhere. I simply flush it and it flushes everywhere. Ofcourse, for that to happen, caching module must use Namespice functions.

The only problem with Namespice is it doesn't support DB cache backend yet, but it's possible to fix with backend detection and switching to direct SQL cache flush queries.

Comments

crea’s picture

crea commented
Status: Active » Closed (fixed)

Hmmmmmm....looks like there will be a problem because for many module to use same Namespice tags, same serial storage would be needed.
Anyway, take a look at this if you are interested..

mikeytown2’s picture

mikeytown2 commented

Will this scale to the Million+ node level?

crea’s picture

crea commented

With Memcache it must, APC don't know. I heard about segmentation problems APC has with many entries (though they can be dealt with giving APC more memory). AFAIK Memcache also uses more memory than cache really needs because of inefficient but very fast slab allocation. So the general policy is just to put in as much memory as you can.
I'm not DB expert, but I guess sites with millions of cache entries won't be running DB cache anyway.

crea’s picture

crea commented

About the problem I mentioned above: I have some ideas how to workaround it, so if you are interested, reopen this issue. You have made in the Boost module great progress in implementing cache invalidation patters. Would be pity to not use them outside of the Boost.

crea’s picture

crea commented

Some more thoughts: it seems transparently supporting all cache backends in Namespice would be not easy task. For example there's memcache.db.inc backend, which caches both in memcache and in DB. Though it's probably bad idea to cache in memory and at the same time slow itself with DB, there are people who use that configuration. That raises one big question for me: is it worth to support such low performance configuration (any type of DB as backend), while the whole reason for making Adv. Panels Cache and Namespice was highest performance.
So while I in Namespice can simply not support such configuration, with Boost you probably have widest audience and any type of configuration as requirement. So for the reason of compatibility, it may be bad idea to integrate Boost with Namespice.
Thanks for ideas anyway.

crea’s picture

crea commented

Besides, APC seems to be not having LRU. Such a shame...So, I may leave Memcache the only supported backend :(
That certainly kills any reason for Boost to integrate with Namspice.