[wp-trac] [WordPress Trac] #60011: 6.4.1 seems to deliver poor external cache performance compared with 6.3.2

[WordPress Trac]

#60011: 6.4.1 seems to deliver poor external cache performance compared with 6.3.2
--------------------------+------------------------------
 Reporter:  bjornha       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Cache API     |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by bjornha):

 Replying to [ticket:60011 bjornha]:

 Forgot (at least) one relevant piece of information. All sites are running
 WP Redis 1.4.4 as object cache when these figures were measured, both
 6.3.2 and 6.4.1

 > Hello,
 >
 > After upgrading WordPress from 6.3.2 to 6.4.1 I noticed a performance
 degradation and started to investigate. The upgrade was done on our
 staging site, where as the production site still runs on 6.3.2
 >
 > I went through all plug-ins and made sure that staging and production
 had the same code base and system running except for the WordPress
 versions.
 >
 > We use Redis version 6 as central cache for our sites, that all run on 2
 instances in Azure Web Services for Linux, using PHP 8.2 as base.
 > The cache miss rate has constantly been ~10% on version 6.3.2 but
 increased to ~34% on version 6.4.1.
 >
 > I have run the two setups side by side over the weekend and had a
 similar load on the sites and the figures above seem consistent over time.
 >
 > I have nothing more specific to share as to which lookups that fail, but
 it seems consistent over WordPress and plug-ins using the external cache.
 >
 > I have had a look on Pods behavior together with Pods support as I at
 first after upgrading saw a 1000% increased page load time and Pods was
 generating most of it. At this point the cache showed a missrate of >70%.
 >
 > But after saving Pods settings in 6.4.1, the update of alloptions seemed
 to get rid of that specific overhead and Pods were performing as the rest
 of the plug-ins.
 >
 > This is how I realized that the increased load time in 6.4.1 might be
 cache related as the miss rate did not go below 30%.
 >
 > As stated above, I have no firm examples of erroneous calls to share, it
 seems to be a general behavior.
 >
 > I am also attaching a link to an image showing Redis cache behavior with
 6.3.2 on top, 6.4.1 below.
 >
 > If Cache API is the right component for this, I dont know, but it seemed
 to be close to my obeservaton.
 >
 > Kind regards,
 > Bjørn Hasselberg
 >
 >
 [[Image(https://pro4uadmin.blob.core.windows.net/wordpress/6.3.2%20and%206.4.1%20cache.png)]]
 >

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