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

[WordPress Trac]

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

Comment (by jeremyclarke):

 Argh! I guess this isn't going to be fixed in the 4.4? We're using the
 Redis object cache (just to add a little flavor) and this bug is causing
 white-screen-of-death on sites that it affects until the cache is cleared
 (which is a huge hit to our server as it stores multiple sites but you can
 only clear them en-masse).

 '''Alternate idea'''

 Currently when you change an autoloaded option it updates the option cache
 with old-alloptions+your-change, and the problem is old-alloptions might
 already contain out of date values. So here's my question:

 Why not just delete the alloptions cache completely, rather than updating
 it. It's described in this ancient+closed forum thread:

 https://wordpress.org/support/topic/caching-of-options?replies=2

 It wouldn't be as fast as the current way, but would avoid the race
 condition (since subsequent pageloads would get a fully fresh copy). The
 downside is that alloptions needs to get totally reloaded, but loading it
 in is fast anyway right?

 AFAICT the problem is that a system which fetched or saved options to the
 cache individually would be much much slower, but the system for
 getting/setting them together is fast. This implies that we should still
 get decent performance letting the whole cache be reloaded at once even if
 it happens more than we'd like.

 Dumping the whole cache when a field is updated is simple and seems like
 it would solve the problem without any concerns about compatibility with
 the "multi" options of other plugins. This is especially important once
 you factor in non-mecached servers, since e.g. Redis has very different
 support for bulk handling of keys.

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