1

I’m hoping this is something easy to fix although from my tests (very new to WordPress so please go easy with me if these tests are not very good!) doesn’t appear to be.

I have a site hosted on SiteGround which was eating through the CPU seconds like nobody’s business.

I’ve now managed to put it down to the Heartbeat API calling the admin-ajax.php file so much.

Small question about admin-ajax.php if I may? Am I correct in my thinking that this file is only ever fired if someone is actually logged into the control panel and not under any other circumstances such as someone just visiting the site?

To that end I found some code on the internet which is shown below :

add_action( 'init', 'stop_heartbeat', 1 );
function stop_heartbeat() {
wp_deregister_script('heartbeat');
}

I read that this goes into the functions.php file of my theme at the very top after the opening < ? tag.

I’ve placed it there however I’m fairly certain that the Heartbeat API is still running despite this.

Am I correct in my thinking that the Heartbeat API is what is responsible for when one user is editing a post and another user tries to edit it and they get a message warning them someone else is already editing that post?

If so then I am still getting those messages even with this code in place and with two completely different users on 2 completely different browsers.

I’m testing this on a localhost machine as don’t want to mess with the live site currently however this is a completely vanilla install of WordPress 4.8.1 with absolutely no plugins or custom themes being used. Just the standard 2017 theme.

So my questions would be :

1 – Is it even possible to turn off the Heartbeat API or is it a known issue that it actually can’t be turned off?

and

2 – If it definitely can be turned off then what am I doing wrong?

Thanks for any help with this.

Best wishes,

Mark

1
  • no, the heartbeat api is unlikely to cause any performance issue. Sep 17, 2017 at 11:32

1 Answer 1

2

Am I correct in my thinking that this file is only ever fired if someone is actually logged into the control panel and not under any other circumstances such as someone just visiting the site?

No, Ajax API is used for arbitrary requests, including those for the front–end and non–authenticated users.

Am I correct in my thinking that the Heartbeat API is what is responsible for when one user is editing a post and another user tries to edit it and they get a message warning them someone else is already editing that post?

While Heartbeat API was implemented for such functions, it's more of a generic channel arbitrary things can run on top of.

Is it even possible to turn off the Heartbeat API or is it a known issue that it actually can’t be turned off?

As far as I remember it is exceptionally hard to disable, more so in clean and compatible way. It also went through several approaches, so a lot of related snippets online are outdated and irrelevant. If there is a sane way to turn it off as of right now — I am not aware of it.

If it definitely can be turned off then what am I doing wrong?

Not sure if you do anything wrong. This might be better discussed with hosting support. Might be something is messing it up, might be your needs (such as many logged in users in admin) are larger than your plan. Anecdotally I am long time SiteGround user myself and never had Heartbeat API issues with them.

4
  • 1
    Hi Rarst. Thanks for the detailed response there, very much appreciated. Okay so if the API can't be turned off I'll have to report this on the WordPress ticket system as that's definitely a big in my eyes then. The admin-ajax.php file is being called by the server IP literally thousands of times a day and so is using up a massive proportion of the 40000 CPU seconds available daily (on the GoGeek plan). There's no way that it should be doing that although I'm not too sure of how to find out exactly what is calling it and Siteground have said I'd need to get a dev to take a look.
    – Mark Bowen
    Sep 17, 2017 at 12:52
  • They said they can see the file is being accessed lots but that's all the information they can give me. They won't tell me what's actually calling the file and that I'd need to get a developer to look into that. Not too sure how a developer who would have the same access as me would be able to see anything different though? Is there some way of me finding out what is calling that file?
    – Mark Bowen
    Sep 17, 2017 at 12:53
  • I think developer would have to hack in bit of logging in your case to figure things out, unfortunately I don't think I have anything ready-made on hand that would help in your case.
    – Rarst
    Sep 17, 2017 at 15:46
  • Hi Rarst. Thanks again for the info. Don't really like the sound of hacking to be honest ;-) especially on a live site. What I don't get is why it can't even be turned off on a completely brand new install of the latest WordPress with absolutely no custom plugins or anything in the system. Definitely a bug as far as I'm concerned so I've put in a ticket at WordPress. Hopefully that was the right thing to do?
    – Mark Bowen
    Sep 17, 2017 at 17:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.