[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:  closed
 Priority:  normal                               |   Milestone:  5.3.1
Component:  Options, Meta APIs                   |     Version:  2.1
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch needs-testing needs-dev-   |     Focuses:
  note                                           |  performance
-------------------------------------------------+-------------------------

Comment (by lisota):

 After running this fix in production for a few months now, I want to
 document that the alloptions race condition still exists in some
 circumstances.

 Our site runs [https://wordpress.org/plugins/redis-cache/] from Till
 Kruss. Our site also uses HyperDB with a write master and a read slave. We
 have a healthy amount of traffic, typically we have ~50 reqs/sec or so,
 but that number is highly variable.

 At periodic and unpredictable times, the server load on our Redis server
 will jump from 20% to 100%, rendering the site inoperable as Redis times
 out repeatedly. The logs show hundreds of events doing calls to set the
 alloptions cache, which in turn tries to save it in Redis. Clearly there
 is still a race condition possible here.
 {{{
 wp_cache_set('alloptions', Array, 'options')
 WP_Object_Cache->set('alloptions', Array, 'options', 43200)
 Redis->setex('1:options:allop...', 43200, 'a:568:{s:7:"sit...')
 }}}

 In the case of our site, the calls to writing alloptions to the cache come
 from a few different plugins. Jetpack's sync function does it. So does
 [https://wordpress.org/plugins/safe-redirect-manager/] and
 [https://wordpress.org/plugins/the-events-calendar/].

 I am curious from @spacedmonkey what the experience has been on VIP Go
 with this new functionality introduced in 5.3.1 and whether the previous
 patch remains in place in production.

 Also @SergeyBiryukov, @dd32, @fabifott  note that this patch may have
 improved, but evidently did not fix the potential for alloptions race
 conditions when used with an object cache.

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