Make WordPress Core

Opened 15 months ago

Last modified 7 months ago

#60011 new defect (bug)

6.4.1 seems to deliver poor external cache performance compared with 6.3.2

Reported by: bjornha's profile bjornha Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 6.4
Component: Cache API Keywords:
Focuses: performance Cc:

Description

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

https://pro4uadmin.blob.core.windows.net/wordpress/6.3.2%20and%206.4.1%20cache.png

Change History (8)

#1 in reply to: ↑ description @bjornha
15 months ago

Replying to 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

https://pro4uadmin.blob.core.windows.net/wordpress/6.3.2%20and%206.4.1%20cache.png

#2 @johnbillion
15 months ago

  • Focuses performance added
  • Version changed from trunk to 6.4

#3 @johnbillion
15 months ago

Thank you for the report @bjornha, and welcome.

Are you able to find out if the keys for the misses are consistent across page loads? I know this can be difficult, especially with a large number of cache entries. The WP Redis plugin does provide a WP-CLI command for debugging which might be worth trying (wp redis debug).

#4 @bjornha
15 months ago

The output from wp regis debug is quite limited, only aggregating values, not specifying actual keys.
What I do see as difference when calling the 6.4.1 environment is that it does not seem to try to mitigate misses.
In 6.4.1 I consistently get the same figures for all calls and there are no “sets” being reported at all.
For instance, in 6.4.1 this:
wp redis debug --url=https://testwpadmin.pro4u.se/avtalslista
leads to this:
array (

'cache_hits' => 21486,
'cache_misses' => 41,
'redis_calls' =>
array (

'get' => 98,
'mget' => 7,

),

)
No change ever here.

In 6.3.2 I see this behavior.
After first call:
array (

'cache_hits' => 37023,
'cache_misses' => 24,
'redis_calls' =>
array (

'get' => 76,
'mget' => 7,
'set' => 3,

),

)
After second call
array (

'cache_hits' => 37030,
'cache_misses' => 21,
'redis_calls' =>
array (

'get' => 76,
'mget' => 7,

),

)
Here you can see that cache misses goes down with the amount of “sets” that was done in the previous call.
But I don’t know how useful this is as it does not specify actual actions towards Redis.

/bjørn h

#5 @bjornha
15 months ago

6.4.1 now upgraded to 6.4.2, same status.
/björn h

This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.


14 months ago

#7 @svyazy
14 months ago

We had to revert from WordPress version 6.4.2 to 6.3.2 due to the same performance issues with external caching.

We are utilizing an AWS Redis Cache cluster version 6.2.6 and Redis Object Cache 2.4.4 plugin as the object cache, alongside PHP 7.4 as the base platform.

After upgrading WordPress to version 6.4.2, our Cache Hit Rate decreased from an average of 99% to 40%. Additionally, Memory Fragmentation Ratio increased from 1.04 to 2.9, and there was a spike in String Based Command Count.

Last edited 14 months ago by svyazy (previous) (diff)

#8 @bjornha
7 months ago

Just thought I would mention that the behaviour is present in all versions we have used from 6.4.1 up to latest version of 6.5.X. If 6.6 behaves differently I will come back and comment.

Note: See TracTickets for help on using tickets.