[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 azaozz):

 > ...it is definitely the large number of post lock refreshes via admin-
 ajax.

 One reason may be that refreshing the post lock writes to the DB.
 Unfortunately I don't see a way to make this less frequently. The locks
 "last" for 150 sec. If the browser window is "blurred", the next refresh
 will be in 120-135 sec. plus connection time.

 The only way to decrease the frequency of writing to the DB would be to
 (substantially) increase the time locks last. However that brings other
 problems: the lock should be released when the user navigates away from
 the Edit Post page. The only way this could be done is by another AJAX
 request, but since that request fires on window.unload, it is sometimes
 unsuccessful.

 `jQuery(document).off('.refresh-lock');` would work well. Another way
 would be from PHP by removing the filters `add_filter(
 'heartbeat_received', 'wp_check_locked_posts', 10, 3 );` and `add_filter(
 'heartbeat_received', 'wp_refresh_post_lock', 10, 3 );`.

 Everything in Heartbeat is based on filters, both in JS and PHP, so
 controlling it should be easy. The same is true for `remove_filter(
 'heartbeat_settings', 'wp_heartbeat_set_suspension' );`.

 > I hope that as the Heartbeat API makes it into more features (i.e.
 autosave), that there can be some testing on high-traffic sites that
 intensively use the post editor.

 This has been working on WordPress.com and other huge sites without
 noticeable increase of server load. Seems the most impact is on medium and
 large sites.

 Disabling the updates of post locks will certainly reduce server load as
 writing to the DB always takes more resources. Been thinking about ways to
 make that more efficient, perhaps storing the locks in persistent memory
 cache (when available) and "flushing" them to the DB every 30 min.

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