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

WordPress Trac noreply at wordpress.org
Wed Feb 12 20:22:19 UTC 2014


#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):

 Replying to [comment:5 lisota]:
 > The heartbeat API, specifically the wp-refresh-auto-lock, is a major CPU
 hog. I can easily max out our 8-core server by opening 15-20 edit post
 windows and having them all hitting the server with refresh post lock
 requests every 15 seconds. Logging out of those screens quickly reduces
 CPU to under 10%.

 Before Heartbeat, (WordPress 3.5) the Edit Post page was connecting every
 minute for autosave. In 3.8 Heartbeat connects every 15 sec. for the
 "focused" page and every 2 min. for the "non-focused" pages. So if you
 have 5 people that have 4 Edit Post pages opened at the same time in 3.5
 you'll always see 20 connections per minute.

 In 3.8 there will be 20 connections for the focused pages (5 pages x 4
 connections) plus 8 (average) for the non-focused pages (15 pages x 0.5
 connections). In addition there may be up to 5 connections per minute if
 the posts in the focused pages are being edited as autosave would connect
 when there are changes.

 On average there will be about 50% - 60% (20 vs. 30-33) more connections
 in 3.8 compared to 3.5. Also in 3.9 autosave uses heartbeat for transport
 reducing the number of connections to 28. This number is higher but is not
 even two-fold.

 > I tried deregistering heartbeat everywhere, including post.php and post-
 new.php. However, that seems to affect another AJAX function, the ajax tag
 search no longer works.

 Deregistering heartbeat.js on the Edit Post screens is not a good idea. It
 would also stop post.js from loading (as heartbeat.js is a dependency for
 post.js).

 You can increase the interval to 60 sec. in couple of ways. From JS:

 {{{
 jQuery(window).load( function() {
   if ( window.wp && wp.heartbeat ) {
     wp.heartbeat.interval( 60 );
   }
 });
 }}}

 This has to run after `jQuery(document).ready()`, hence the
 `jQuery(window).load()`.

 From PHP:

 {{{
 add_filter( 'heartbeat_send', 'my_heartbeat_settings' );
 function my_heartbeat_settings( $response ) {
         if ( $_POST['interval'] != 60 ) {
                 $response['heartbeat_interval'] = 60;
         }
         return $response;
 }
 }}}

 This will reset the interval to 60 sec. on every "beat" regardless of the
 current page and the initial settings.

 Of course changing the interval will impact the Post locking
 functionality.

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


More information about the wp-trac mailing list