update_blog_details() performance improvement ideas

[boonebgorges]

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.

[ocean90]

Related chat: ​https://wordpress.slack.com/archives/core-multisite/p1475069323000604

[johnjamesjacoby]

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.)

[boonebgorges]

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.)

[johnjamesjacoby]

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.

[flixos90]

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.

[boonebgorges]

Duplicate of #40364.

Thanks!