[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 fixed-major  |     Focuses:
                                                 |  performance
-------------------------------------------------+-------------------------

Comment (by lisota):

 Replying to [comment:75 spacedmonkey]:
 > Replying to [comment:74 johnbillion]:
 > > Is it also in place on VIP Go?
 >
 > Yes it is - https://github.com/Automattic/vip-go-mu-
 plugins/blob/master/misc.php#L73-L85

 Now that there is a fix in place in WP 5.3.1, is it important to remove
 the previous fix for the alloptions race condition?

 I think our site was experiencing a similar race condition when running WP
 5.3.1 alongside the original fix from VIP Go (which we have used
 successfully for years with our Redis object cache instance)

 I haven't been able to diagnose fully, but we've been getting timeouts on
 our Redis instance causing site lags during the past few weeks.

 The error logs indicate timeouts around calls like this:
 WP_Object_Cache->get('alloptions', 'options', false, NULL)

 I have removed the alloptions fix, which seems to have fixed the issue.
 Just not wrapping my head around what was happening when the VIP Go
 alloptions fix was running alongside WP 5.3.1.

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