new wp_maybe_auto_update behavior can cause problems with large number of installs

[growlingoctopus]

The changes introduced in [25825] can create issues on large servers, such as shared hosting servers. There are actually 2 different bugs here:

1) According to the code this should set the cron to the 7:00 hour (am and pm) server time. It doesn't usually do that, because this time is generated with strtotime('today 7am'), and in wp-settings.php the timezone is manually changed to UTC. In most installs, the gmt offset is 0 and the timezone_string is blank, so these don't get properly applied either. EG, on servers in central time, the updates really run during peak hours at 2 PM.

2) On servers with large numbers of installs, this can cause major issues. There's the upgrader_scheduled_cleanup which calls wp_delete_attachment() for the upgrade files to clean up. This searches things like comment tables for comments attached to the 'attachment' (even though there usually aren't any for this particular one, or are there ever?) Since these are scheduled for exactly 2 hours after the upgrade, all of these will run during the same hour as well, which can cause extremely high I/O as all of these tables for many different databases are read through.

The easiest way to fix the base problem for this would be to go back to a fully random time for these updates. Another option is to have a blackout config option added, or have a static blackout window during the day. The problem with these though is they would make it hard to do the twicedaily setup. Also, the timezone issue should probably be corrected if the code is kept in its current state, or it will run at unintended times.

[nacin]

[26149] made this a bit better. It was originally scheduled for exactly 7am and 7pm, which in hindsight was quite a mistake. It's now spread out over the full hour, from 7-8.

[28129] made some further changes by making it so the randomly scheduled twice-daily update checks could also trigger an auto update. This means that we now could trigger an update before the next 7-8 window, if there's a core check already scheduled during that time.

A lot of sites definitely don't have a timezone configured, and it's surely the most popular, but our API traffic network graphs suggests it's definitely not most sites.

You'll note that [28129] is actually for narrowing the update window. Eventually we'd like to be able to perform all updates in under an hour, globally. While we know we can handle that traffic on .org (and we've made quite a lot of adjustments to do so), the worry is of course causing shared host problems. Because we have the ability to narrow the update window, I'd be perhaps OK with ditching the 7-8 window and going fully random, but it doesn't help all that much with our long-term goals.

The wp_delete_attachment() part is definitely interesting. We could schedule that for a random amount of time between 2 and X hours without much of an issue.

[dd32]

Over the years since we first rolled out Background Updates we've shifted from having all updates occur at a scheduled time, to core updates being scheduled to happen within roughly a 1 hour window.

The benefits of rolling out security fixes fast to a majority of sites outweighs the problems experienced here, and with our partial build support the amount of file IO operations is significantly smaller for a core background update than a regular user-initiated update.

Feedback from hosts to myself in discussions has pointed that many hosts did indeed have issues with the extra load, however now take that into consideration.

I don't think we will be making any changes here, so I'm closing this off.