[wp-trac] [WordPress Trac] #60053: Improve cache flush handling for large multisite database upgrades

[WordPress Trac]

#60053: Improve cache flush handling for large multisite database upgrades
------------------------------------+-----------------------------
 Reporter:  xParham                 |      Owner:  (none)
     Type:  enhancement             |     Status:  new
 Priority:  normal                  |  Milestone:  Awaiting Review
Component:  Cache API               |    Version:
 Severity:  normal                  |   Keywords:
  Focuses:  multisite, performance  |
------------------------------------+-----------------------------
 We run a large WP multisite (200 sub-sites) and with recent WP major
 version upgrades, the upgrade process has caused a significant performance
 drop while the database upgrade was in progress, causing downtime and 503
 server errors. This seems to be mainly due to multiple back-to-back
 flushing of the object cache, network-wide, while the sites are under
 traffic.

 In `wp_upgrade()` I see two calls to `wp_cache_flush()` which would happen
 for each of the subsite DB upgrades and I was wondering if things can be
 improved there.
 - Could we make the cache flush to be more selective and drop specific
 groups rather than dropping the whole network cache?
 - Could we do only one cache flush at the end of the DB upgrade for all
 sites instead of dropping the cache for each of the subsites' DB upgrades?
 - For object caching implementations that support subsite cache flushing
 (e.g. OCP) could we maybe utilize that feature?

 I have attached some logs and reports from our APM. This was for upgrading
 from WP 6.3.x to 6.4.x, using Redis with Object Cache Pro, and 4GB of
 cached items.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60053>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform