[wp-trac] [WordPress Trac] #62692: Performance regression for get_option in 6.4

[WordPress Trac]

#62692: Performance regression for get_option in 6.4
--------------------------------------+------------------------------
 Reporter:  rmccue                    |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Cache API                 |     Version:  6.4
 Severity:  major                     |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+------------------------------

Comment (by rmccue):

 Replying to [comment:13 siliconforks]:
 > It seems like what you really want is this:
 >
 > 1. Check `alloptions`
 > 2. Check `notoptions`
 > 3. Check the cache for the specific option
 > 4. Check the database for the specific option
 >
 > Does that make sense?

 If we can, I can see that making sense; seems a good split between the
 original intention (lowering calls for the common path) and improving the
 worst-case scenario. There's a slight possibility of cache confusion if a
 value is set but isn't deleted from `notoptions` due to a race condition
 or similar - I think the likelihood of that is low (not zero; see #31245
 for prior alloptions bugs along those lines), and no worse than before
 from what I can see.

 Replying to [comment:12 spacedmonkey]:
 > Sites with cache missing and none object cache site has notable
 benefits. Revert this was effect those users to super serve a number of
 users using redis implementations.

 I understand this perspective, but I'm also comparing a slight performance
 decrease for many users against a ''catastrophic'' hit to performance at
 scale which caused a multiple day intermittent outage and massively
 increased cache server traffic. We can ignore the singular incident if
 you'd like for this conversation, but even just from a purely theoretical
 standpoint the original patch was problematic in causing excess reads.

 Also from the original ticket, I don't see that there were ''notable''
 benefits, but maybe I'm misreading those results.

 I take your point on the delay in feedback - we didn't notice for other
 customers as our systems automatically scaled up for the additional load,
 and we're using alternative object caches which don't have this problem.

 > I guess I don't understand why the mountain is moving here, when this is
 for the object cache plugin maintainer to pick to fix this.

 I think we should likely do some advocacy to have these caches act
 consistently, but as noted in my investigation above, it's inconsistent at
 best; it affects most implementations that I checked.

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