For a Digg event there will be just one cached version of the page—generate once, serve many—not a torrent of new cache entries.

I didn’t really explain myself very well here. With full-page caching, there’ll be only one version of the page, but still hundreds of dead versions from the “first comment!” commenting – since the torrent of digg pageviews will invalidate everything else out of the cache.

Without full-page caching, it’s even gloomier; hopefully some global variables (alloptions?) will be fairly unchanged.

Anywho – this all was a parenthetical to support that cache invalidation is likely to best be weighted entirely on how ‘hot’ each entry is (I had originally thought entries with more hits should stay for longer, but this example neatly invalidates (ha!) that idea).

Were you aware that $wp_object_cache->global_groups is unused? WordPress.com uses it to great effect.

I knew it didn’t feel particularly used. I suppose it only makes sense in a MU setting? I didn’t know what ‘global’ meant; now I do, I think.

For example, if ( $group == ‘persistent’ ) { store in the database } else { store in memory }.

Magic groups!

It seems a little rearchitecturing is in order; perhaps multiple backing storages can be implemented via configuration; there’ll need to be a WP_Cache_Master to control all the WP_Cache_Database, WP_Cache_Memcached, etc.

Maybe make the Cache_Master as a plugin, and have it take many subclasses of WP_Cache_Base as different backing stores. The _Master configuration could specific which groups get stored where?

if a slashdot effect yesterday caused one cache entry to be hit 10,000 times, today’s digg effect on a different page will quickly knock the old cache entry off – since the torrent of new cache entries created by the dugg page will give the slashdotted page’s caches the oldest last accessed date

For a Digg event there will be just one cached version of the page—generate once, serve many—not a torrent of new cache entries.

Another way to implement this would be through the group mechanism already in WP_Object_Cache.

I implemented it by passing arrays of tags to the group argument. We have some other logic piggy-backed on the group arg, so it seemed natural. The first array value is treated as a group. A private method constructs the cache array key out of the tags and their versions. Tags could be a separate argument but this was leaner—probably what you had in mind.

The things you can do with tag one—the group—are limited to your imagination. Were you aware that $wp_object_cache->global_groups is unused? WordPress.com uses it to great effect. It just occurred to me that in core you could have several cache stores lumped into one and use the group to determine what went where.

For example, if ( $group == ‘persistent’ ) { store in the database } else { store in memory }.