Make WordPress Core

Opened 20 months ago

Closed 20 months ago

Last modified 20 months ago

#56845 closed defect (bug) (fixed)

Multisite option caching breaks for sites with bigger options

Reported by: pavelschoffer's profile pavelschoffer Owned by: davidbaumwald's profile davidbaumwald
Milestone: 6.1 Priority: normal
Severity: critical Version: 6.1
Component: Options, Meta APIs Keywords: commit dev-feedback needs-dev-note
Focuses: multisite, performance Cc:

Description (last modified by desrosj)

This change ( changed the way multisite options are retrieved and cached in trunk (to be released in 6.1.).

The old code used to put to cache each requested site meta (=network option) separately under a key: <network_id>:<option_key> so for example 1:site_name.

The new code fetches all the options for the given network_id (not just the one you are asking for) and saves the whole set of them under one key :site_meta:<network_id> so :site_meta:1. Where the value in the cache would be:

   "site_name": '...',
   "option2", '...',

The outcome of this change is that if the cumulative size of ALL site options is bigger than 1MB (default limit of memcached per object) NONE of the options will be cached.

Would it be possible to revert the change and/or make the cache key per-site versus per-site-and-option-key optional?

Attachments (1)

56845.diff (35.3 KB) - added by davidbaumwald 20 months ago.
Revert patch

Download all attachments as: .zip

Change History (12)

#1 @desrosj
20 months ago

  • Description modified (diff)

#2 @desrosj
20 months ago

  • Milestone changed from Awaiting Review to 6.1

#3 in reply to: ↑ description @rebasaurus
20 months ago

The outcome of this change is that if the cumulative size of ALL site options is bigger than 1MB (default limit of memcached per object) NONE of the options will be cached.

If none of the options end up being cached, it will attempt to add them to the cache on each request (e.g. if it never succeeds, it will continue to do so over and over). A sample stacktrace would be:

get_network_option() -> get_metadata_raw() -> update_meta_cache() -> wp_cache_add_multiple() -> wp_cache_add() -> MemcachePool->add()

#4 @johnbillion
20 months ago

  • Focuses multisite performance added

#5 @johnbillion
20 months ago

Another concern is that upon updating to 6.1, all existing network option caches will be invalidated because the cache key has changed. That might cause a stampede on sites that are caching a lot of data in network options.

This ticket was mentioned in Slack in #core by chaion07. View the logs.

20 months ago

20 months ago

Revert patch

This ticket was mentioned in PR #3488 on WordPress/wordpress-develop by @davidbaumwald.

20 months ago

  • Keywords has-patch has-unit-tests added

PR to test GHA to ensure the revert works.

#8 @desrosj
20 months ago

  • Keywords commit dev-feedback added; has-patch has-unit-tests removed

Marking as first commit review.

#9 @davidbaumwald
20 months ago

  • Owner set to davidbaumwald
  • Resolution set to fixed
  • Status changed from new to closed

In 54637:

Networks and Sites: Revert the use of the metadata API for *_network_options functions.

[54080] refactored the logic in get_network_option(), update_network_option() and delete_network_option() to use the metadata API. However, this change resulted in issues with large multisite installs that utilize memcached having network options > 1MB in size.

This change reverts [54080] and all related follow-up changes.

Reverts [54080], [54081], and [54082]. Partially reverts [54267] and [54402].

Props pavelschoffer, rebasaurus, johnbillion, spacedmonkey, desrosj, rinatkhaziev.
Fixes #56845.
See #37181.

#11 @peterwilsoncc
20 months ago

  • Keywords needs-dev-note added

This change was mentioned in the multisite dev note that ought to be followed up:

  • a brief dev-note (one or two paragraph) to note it's been reverted
  • update the original dev note
Note: See TracTickets for help on using tickets.