A couple of days ago I noticed there was something going on with my website.
It took much longer than normal to load and after a few minutes I was getting internal server errors.
I’ve seen this happen once before since I’ve hosted my site with SiteGround.
So I immediately thought it might be the same thing.
A Plugin Went Rogue
I contacted the SiteGround support team because I wasn’t certain it was the same issue.
I could see that my site was using lots of CPU time and was spiraling out of control.
I deleted the plugin I thought could be the problem but that didn’t slow things down.
They responded within a couple of minutes which took me by surprise.
After they disabled all of my plugins, things were back up and running again thankfully.
And the CPU time very quickly went back to normal.
It was a plugin which caused the spike and it’s one that’s done it before so I should have learnt my lesson.
It was the Social Networks Auto Poster at fault and needless to say I won’t be adding it back to my site again.
SiteGround’s support team gave me some helpful advice about lowering my CPU time even further.
Obviously I took their advice.
Was I asleep when the Heartbeat API came out in WordPress 3.6?
At first glance, the functionality which the Heartbeat API provides is useful.
However, it can be a cause of of high CPU usage on your hosting account.
And I had never heard of it.
When I looked at the scripts which were executed on my site, admin-ajax.php was high on the list.
That’s more than likely the Heartbeat API in action.
So, in order to tame the beast, I could either limit it or stop it altogether.
As I’m the only one maintaining my site and I didn’t want to add another plugin, I decided to stop the API altogether.
From what I understand, this won’t have any implications I can’t live without.
Something else which the SiteGround support team mentioned was that there was a fair amount of activity on wp-cron.php too.
It’s a WordPress function which is triggered every time someone visits your site.
I don’t get that much traffic to this blog though that it shouldn’t be an issue.
So I can only imagine the activity had spiked because of the rogue plugin.
In any case, I decided to follow the support team’s advice again and replace the WordPress Cron with a real Cronjob.
Instead of it triggering every time someone loads a page on my site, now it triggers automatically every 30 minutes.
That should slow down the activity on wp-cron.php somewhat and hopefully contribute to lower CPU usage.
Consequences Of High CPU Resource Usage
With many shared hosts if you suffer a cpu resource issue, then you may end up having your account closed.
HostGator will only let you exceed your limit it a few times before you’re left out in the cold for example.
SiteGround restrict your account but don’t close it thankfully.
You’ll have very limited access to your site though unless you upgrade or contact their support team to sort things out.
Whilst SiteGround are a good webhost from my experience, they do set the bar very low when it comes to CPU resource usage.
And it can cause a whole host of issues for people, particularly if you’re a business owner and their restrictions mean your site’s down because of it.
It’s important to optimise your site as much as you reasonably can with SiteGround.
So that means using caching, a CDN and putting in place other measures as I’ve mentioned above.
Do I think SiteGround will increase the limit on CPU resource usage?
Will I stay with them?
Yes, but I would seriously consider a move if I were running a business website.
Have You Ever Come A Cropper With CPU Time?
Have you suffered from restrictions to your web hosting account due to high resource usage?
What was the outcome?
What has your experience been with SiteGround and other web hosts in this context?
Please let me know in the comments section below.