WordPress.org

Make WordPress Core

Opened 10 months ago

Closed 3 months ago

#38828 closed defect (bug) (duplicate)

update_blog_details() performance improvement ideas

Reported by: boonebgorges Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords: needs-patch needs-unit-tests good-first-bug
Focuses: multisite, performance Cc:

Description

I've got a site running a plugin that deletes lots of posts in bulk. This triggers update_blog_details() (long story), which triggers lots of unnecessary UPDATE queries.

The most obvious one that can be skipped is update_option( 'blog_public' ... ). There's no need to run this if the value hasn't changed.

It's a shame that we have to clear all blog caches (refresh_blog_details() -> clean_blog_cache()) every time a blog's last_updated key is modified, but I don't see a way around this that doesn't involve lots of research.

Change History (7)

#2 @johnjamesjacoby
10 months ago

We are slowly starting to replace the _blog_ functions with _site_ equivalents where possible, so this may be achievable sooner than later with a new update_site_details() function.

Or (and this is starting to be my preference) an update() method in the WP_Site object instead.

If I understand the callstack correctly, update_blog_details() should only trigger 2 update calls:

  • To wp_blogs which basically accepts whatever is passed in (yikes?)
  • To update_option() which does a $value === $old_value check before proceeding

I wonder if it might be easier to unhook your call to update_blog_details() when the bulk-action starts, then hook it back in when it's done, and manually call update_blog_details() once at the end vs. when each deleted_postaction fires (which is my assumption, but seems like the obvious one.)

#3 @boonebgorges
10 months ago

I wonder if it might be easier to unhook your call to update_blog_details() when the bulk-action starts, then hook it back in when it's done, and manually call update_blog_details() once at the end vs. when each deleted_postaction fires (which is my assumption, but seems like the obvious one.)

Yes, there are definitely workarounds for my purpose. (Post deletion is a very DB-intensive process, badly in need of bulk features.)

#4 @johnjamesjacoby
10 months ago

Most of WordPress is architected to trigger actions and bust caches when events on individual objects occur, and by-and-large this is the best way to stay thorough and maintain some sanity within the system.

For actions like bulk-actions, updating counts, and updating last-activity (freshness), these are conceptually different in that it's likely to be much more efficient to only take action at the end, with certain per-object actions being superfluous (potentially extremely, I suspect.) Too bad WP_Hook's can't intelligently unhook themselves under certain conditions.

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


3 months ago

#6 @flixos90
3 months ago

As @johnjamesjacoby stated above, we're working on new functions to take over that functionality, and of course we'll try to improve its code and performance as much as we can.

Eventually there will be a wp_update_site() which will be responsible for doing what update_blog_details() does at the moment. @boonebgorges If you agree, I'd rather close this ticket in favor of #40364, where we're working on that new sites CRUD API. I'll put a reference in there, so we know what to look out for in the new code.

#7 @boonebgorges
3 months ago

  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #40364.

Thanks!

Note: See TracTickets for help on using tickets.