WordPress.org

Make WordPress Core

Opened 8 months ago

Last modified 8 months ago

#40171 new enhancement

Object Cache Should Support Namespaces

Reported by: brandonliles Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.2
Component: General Keywords:
Focuses: performance Cc:

Description

Currently if any code (particularly a plugin) needs to delete many different cache keys, the default solution is to call wp_cache_flush(). However, this flushes the global cache which may cause serious performance issues on a live site since it affects all cached data. Furthermore is it probably an extremely rare case that all cached data needs to be purged rather than a subset.

Solution Summary: Support namespaces on wp cache calls so that it is possible to kill ranges of cache keys without flushing the entire cache.

Design:

  1. Cache functions have an optional parameter added to specify cache namespace. The default namespace will resolve to the global cache.
  2. An int value is tracked for each namespace. The current int values for each namespace can be stored in the object cache.
  3. When a caller performs a get/set the current int value for the specified namespace is obtained and the namespace + int value is prepended to the key provided by the caller.
  4. When all cache keys within a namespace need to be cleared, the int value for that namespace is incremented, and all subsequent get/sets will begin using new keys. Memcache will eventually purge the old data.

This adds the slight overhead of maintaining the int values for each namespace but allows selectively killing/invalidating cache keys without flushing the entire cache. If necessary namespace values can be statically cached to avoid getting the same namespace value from memcache several times.

Change History (3)

#1 @danielbachhuber
8 months ago

@brandonliles Are you using an object cache drop-in by chance?

WordPress' internal object-cache.php only stores cache data in PHP memory, which is flushed at the end of the request. I suspect your request is more applicable to persistent object caches provided by third-party drop-ins.

#2 follow-up: @brandonliles
8 months ago

You are correct, however, the reason I'm posting this here is because the interface that all plugins use for a persistent object cache is based on the WP object cache.

#3 in reply to: ↑ 2 @danielbachhuber
8 months ago

Replying to brandonliles:

You are correct, however, the reason I'm posting this here is because the interface that all plugins use for a persistent object cache is based on the WP object cache.

Ok. I don't think it's likely for this change to happen in core, because core itself doesn't implement a persistent object cache and wouldn't benefit from the change.

I'd recommend searching Trac for some prior related discussions, including #4476

Note: See TracTickets for help on using tickets.