[wp-trac] [WordPress Trac] #26050: Continual Admin Page POST (HeartBeats?) Can Cause SQL Connection Issues

[WordPress Trac]

#26050: Continual Admin Page POST (HeartBeats?) Can Cause SQL Connection Issues
-------------------------------------+------------------------------
 Reporter:  optimized-marketing.com  |       Owner:
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Autosave                 |     Version:  3.7.1
 Severity:  normal                   |  Resolution:
 Keywords:                           |     Focuses:
-------------------------------------+------------------------------

Comment (by JacobN):

 I stumbled onto this ticket after an article I wrote about limiting the
 WordPress autosave feature via '''wp-config.php''' with
 '''define('AUTOSAVE_INTERVAL', 86400);''' to cut down on excessive
 '''admin-ajax.php''' executions, seemed to no longer be as effective.

 That's when I discovered the Heartbeat API introduced in WordPress 3.6 and
 I've been spending some time reading and testing it since then. If I'm
 misunderstanding something, please correct me.

 Coming from a web host / system admin's perspective, the nature of the
 WordPress Heartbeat API seems very aggressive by default.

 Most hosts when looking at a customer's CPU usage will simply go through
 your access logs and tell you, well this script is getting a lot of hits
 it must be the culprit. A simple Google for '''suspended admin-ajax.php'''
 or something of that nature shows this is pretty common.

 If I simply login to my admin dashboard, then minimize the window I'm
 still generating roughly 25 PHP script executions per half hour. On a
 fresh WordPress 3.8.1 install on a '''suPHP''' server, each of those
 '''admin-ajax.php''' PHP script executions used on average about '''0.2
 seconds of CPU time''' doing absolutely nothing.

 That might not seem like a lot of activity, but imagine the scenario of a
 single shared hosting account that has let's say 10 separate WordPress
 installations running from it. If each of those WordPress installs was
 setup for a different client, you could easily have 10 unique admin
 dashboards logged into at once.

 So in a half hour, we could see:

 25 PHP executions @ (0.2 CPU seconds) = 5 CPU seconds
 5 CPU seconds * 10 admin dashboards = 50 CPU seconds

 Still not terrible by any means with just under 1 CPU minute per half-hour
 of logged in admin activity doing nothing.

 But if all those stayed logged in all day (we see this more than I'd like)
 that'd be close to 40 CPU minutes of PHP executions, effectively doing
 nothing other than POST'ing to '''admin-ajax.php'''

 This of course would be a rare case, but the same applies to the handling
 of '''wp-cron.php''' which is wasteful by nature at doing nothing, unless
 you '''define('DISABLE_WP_CRON', 'true');''' in your '''wp-config.php'''
 and then use a real cronjob to schedule the '''wp-cron.php''' script to
 run on a reduced set interval, instead of the default of calling the
 script every single time a bot hits the site, just to ask, OK '''wp-
 cron.php''' do I have anything to do yet?

 If possible, I'd like to also see an easy to turn off ability for the
 Heartbeat API. Not very many people would have to use it, but for
 customers that are already right at the brink of going over shared CPU
 limits and needing a VPS or dedicated platform to handle more, using up
 CPU time to check if anything needs to be done on a set interval of a
 minute or two isn't ideal. I would think this would be especially true if
 you're hosting in the cloud and paying by the CPU cycles.

 It's not uncommon to see shared servers from multiple hosts that would
 have hundreds of WordPress installations spread across the box. In
 instances like these, I'd worry about all the additional PHP overhead on
 the server's total health, as well as all of the Apache connections being
 used up to handle all the POST requests, or as has been talked about here
 the SQL overhead from all that.

 I don't think the WordPress Heartbeat API is a '''CPU hog''' per se, but
 it definitely has some qualities that could turn it into one given the
 right environment, just like '''wp-cron.php'''. So it would be handy to
 not have to modify your '''functions.php''' script and use a function to
 turn it off on all or certain pages.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/26050#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform