Long time readers will know how much this blog has struggled with its various incarnations over the past 4 years. Initially I ran it from home on a server that I was using for development purposes so it ran inside a virtual machine that contained not one, but two database engines (MS-SQL for development and MySQL for the blog) all behind the tenuous 1.5Mbit upstream connection. This held up ok until I wanted to do anything fancy like put pictures on there (which would kill the connection for anything over 50kb) and it was relatively unstable, going down for days at a time since I couldn’t get a reliable remote connection to it. Since then I’ve churned my way through different virtual private servers (and all the issues they have) before landing on my current Burst.NET Ubuntu box which has been the best of the bunch so far.
Well, on the surface at least.
Since my blog as attained a steady amount of traffic it usually doesn’t take long for someone to pipe up when it goes down, especially if it happens during the day time in Australia. Since I now have remote access to the server I’m one command away from rebooting it should anything happen to it and have done so multiple times when it has come to my attention. However there’s a good 12 or so hours during the day when I’m not really paying attention to the blog due to being at home and/or sleep and downtime during this period usually goes unnoticed until I try to login during the morning. Since a good chunk of my audience is in the USA this can mean an awful amount of missed traffic which isn’t the greatest way to start the day.
Now when I first set up the blog on this host there were a couple teething issues (mostly due to my rusty Linux skills) but for probably 2 months afterwards everything ran without the slightest indication of an issue. Then every so often the blog would simply stop responding, the server would be up and everything else on it was running fine but try as I might I couldn’t get it to serve out a PHP page. Wanting to get it back up as quickly as I could I recycled the Apache service and it came back up instantly and I figured it was just some transient error and went back to my everyday blogging routine. However it kept happening, usually at the most inopportune times, and so last weekend I sat down to find the root cause of the issue.
Turns out its WordPress itself.
The above screenshot shows the error pretty quickly, essentially Apache has reached the maximum number of clients it can serve and will start to reject users after that point. Whilst the causes of this are wide and varied it can usually the culprit can usually be traced down to some WordPress plugin or script that’s opening up connections and then not closing them properly. The best way to take care of this is to fix the script in question but since I have little interest in diving into the mess that is PHP I’ve simply upped the MaxClients setting, reduced the time out period and scheduled an Apache reboot to clear out anything that gets stuck open. All of these combined seems to be an effective solution to this issue in the mean time and once I feel up to the task of delving through all the code to find the offending script I’ll nip it in the bud for good.
Apart from that little quirk though this iteration of the blog’s underlying infrastructure has been pretty fantastic with all the plugins functioning the way I expect them to without me having to fiddle with web.config settings for hours on end. It’s also significantly faster as well, reducing page load times by half for dynamic pages and becoming near instant when its served from cache. You could attribute this to the fact that it’s a lot beefier than its predecessor but neither of them showed significant load for an extended period of time. I guess where I’m going with this is that if you’re going to host your own WordPress blog it’s just plain better on Linux, especially if you’ve better things to be doing (like, you know, blogging).
