[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:8 flixos90]:
 > I'm not opposed to a revert given the performance feedback, but we
 should still weigh off whether that's the right decision. Given this
 feedback comes ~1 year after the 6.4 release, it also feels excessive to
 revert, as nobody reported this before.

 Such is the pace of enterprise customers :)

 FWIW, we have observed a definite increase on other customers, but not to
 the same extent.

 I've attached data from 6 other customers who all have the same pattern of
 an increase in cache traffic after upgrading to WP 6.4. Data is all the
 same window, 15 months, but they upgraded at different times.

 In these cases, we didn't notice it as our systems scaled up to cope with
 the additional traffic, but it is clear in hindsight. In
 [attachment:"Screenshot 2024-12-17 at 13.54.37 at 2x.png"], I have also noted
 when the customer switched object cache implementation to our alternative
 one (Afterburner).

 Clearly, it's cache-dependent, but it's also not a clear bug for the cache
 implementation to work the way it does. In our alternative implementation,
 we have authoritative knowledge of which items are stored and so can
 determine misses much more effectively in the cache itself. (The traffic
 would have also reduced in general just based on the way that cache works,
 so I would not read too much into that.)

 > Obviously that doesn't make the issue any less valid, but I think based
 on this being used in production for so long without known issues, we
 should first verify that reverting this wouldn't have adverse consequences
 - as in: Was the original fix just a very minor improvement that is okay
 to revert?

 My larger point here is that I actually do not think the original change
 would have improved performance. The metric used to justify that change
 was the number of calls to the cache, which is not a useful figure to
 judge based off.

 Calling `wp_cache_get( 'notoptions', 'options' )` repeatedly does not
 cause remote calls, because it's part of the cache API that a successfully
 fetched value is stored in memory in PHP (formalised in #55080); in other
 words, calling this repeatedly is effectively guaranteed to be an O(1)
 lookup from memory.

 It was noted in the original ticket that any speedup was minimal (and
 potentially within the margin of error) - I think effectively, it is
 optimising for the wrong metric.

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