[wp-trac] [WordPress Trac] #31245: Replace alloptions with a key cache

[WordPress Trac]

#31245: Replace alloptions with a key cache
-------------------------------------+-----------------------------
 Reporter:  rmccue                   |       Owner:  SergeyBiryukov
     Type:  enhancement              |      Status:  reviewing
 Priority:  normal                   |   Milestone:  Future Release
Component:  Options, Meta APIs       |     Version:  2.1
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  performance
-------------------------------------+-----------------------------

Comment (by dd32):

 I like the simple direction that [attachment:"31245.3.diff"] has gone in,
 but I have two main concerns: In a multi-database-server environment or
 where there's heavy load/lots of requests/second that this just swaps one
 cache race issue for another.

 This "solves" the cache race issue by having the next option get/page load
 pulling the data directly from the database, but in doing so introduces
 two cache race issues:
  1. In a heavy-option-write situation (Where the original cache race issue
 is most present) If an option write occurs in another page request between
 the time the DB Read and Cache set there's a "small" (Depending upon
 server speed/load) margin of time where the same race issue can occur.
  2. In a multi-database environment, #1 is more pronounced if the second
 thread setting the cache is reading from a secondary database where
 there's a likelyhood that the replication time isn't effectively instant.
 For example, take a site that's receiving 100 req/s: 1 thread updates an
 option, 99 threads immediately query their secondary database that's out
 of date by a millisecond and cache the old data.

 The second case above can be worked around by having alloptions queries
 being made against the primary DB server, although that might not be ideal
 for load purposes, but would an easy way to avoid it.

 The first case is arguably better than the current situation though, and
 ''might'' fix it for some sites.

 > I believe this is the best and most simple solution to this error. It is
 also how the meta api works

 Those cases are far more likely to happen with options than meta, as
 options often have a much heavier write load due to the ways that options
 have been used - In a way, that options/alloptions were never designed
 for.

 ----

 The benefit of shifting to multiple cache keys / multi_get() isn't maybe
 as obvious at first, but it works around the above in a fairly performant
 manner as a) race issues are not an issue (Multiple cache keys can update
 independently), b) there's no sudden DB load increase when clearing the
 cache (Not that this is much of an issue with modern servers) and c)avoids
 any per-key limits on the object cache (For example, the 1MB Memcache
 value limit that used to be hit on WordPress.com so often that I think it
 still has logic to split some cache values over multiple cache keys)

 Personally, I like how this issue has been fixed in existing Object
 caches, for example, [https://github.com/humanmade/memcache-object-
 cache/blob/master/object-cache.php#L140 Human Made's Memcache object-
 cache.php] has specific logic for internally converting the core
 alloptions cache to individual cache keys using it's get_multi
 implementation. It solves a lot of the problems that this ticket has, by
 just fixing the bug at the object-cache layer, so that core doesn't have
 to worry about how every different object cache differs.
 (I guess that's also another concern of mine - This change breaking an
 existing cache's implementation of alloptions -
 [attachment:"31245.3.diff"] won't break the above implementation, but
 it'll make it less performant)

 Perhaps an alternate options here is to specifically offload the
 alloptions caching to the object cache? Fix the Core API to do something
 like `if ( is_callable( $wp_object_cache, 'get_alloptions' ) ) { return
 $wp_object_cache->get_alloptions(); } else { /* existing code */ }`

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/31245#comment:81>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform