In the three years since it began, my blog has been through a number of transitions. The most recent being just a few weeks ago. This is a little tale of that experience, offered to help anyone else who might be following a similar path. This little drama comes in the form of three acts. In this first act, we examine the history of the site that lead up to recent events.
My efforts at blogging began in fall of 2007 on the free hosting at WordPress.com. While a fine place to get started, I eventually wanted to tweak WordPress beyond the scope that was allowed on that service. In particular, the desire to include more multimedia content provided the motivation to move the site to a paid host.
Asking around about possible hosting companies, I was referred to BlueHost as being a suitable option. Based upon their apparently good reputation and very cheap pricing, I set up shop over there.
I took advantage of some down-time presented by the aftermath of Hurricane Ike to make the migration in September 2008. Yes, in the wake of Ike, we had about a week when working wasn’t really possible. Even though we had no utility power our home & office, IT infrastructure was functional. So migrating the site gave me something to do.
The BlueHost site was on a shared server, so mine was one of many, many accounts on the hardware. I didn’t have root access, which was likely a good thing ,since at that point I’d have caused more problems than I could solve.
The BlueHost server quickly became home. I tried a new theme framework, tweaking it to meet my needs. I also tried various WordPress plug-ins for Twitter integration, tracking traffic, database backups, etc. As time passed, traffic to the site grew slowly but steadily. For almost two years the site was pretty stable. The only down-time experienced was when system admins did software updates.
Then in Q2 of 2010, the site started to suffer a lot of down-time. Initially, I was told by BlueHost tech support that the problem was an issue with some aspect of my WordPress installation, possibly a plug-in misbehaving. They noted that my site was CPU throttled a lot, suggesting that something was over-taxing the server.
I experimented with various changes and eventually found that the Cross-Linker plug-in that I was using was very inefficient about its use of MySQL. I really liked Cross-Linker, as it automatically inserted links based upon a table of phrases. This was very convenient and made posts a lot more link laden. It gave me a way to include links to reference sites when I was using technical terminology. It also allowed me to direct readers to VUC sponsors when I was mentioning products and services.
I removed Cross-Linker and searched for something new to replace its functionality, eventually settling upon SEO Smart Links as a good alternative.
I also tinkered with the use of a page caching plug-in. This offloads work from the database by caching the pages as they are built. Subsequent access to pages in the cache bypass the database altogether, being effectively static html. This can dramatically speed up a WordPress site.
My suspicion is that when I opened my BlueHost account, the physical server that it was on was lightly loaded. It was essentially on the front-line as their business was expanding. As they added more and more new accounts, not only did it take on a heavier load, but it was subject to the programming foibles of some perhaps less than enlightened customers.
While my few changes helped to make the site a bit more stable, it was still suffering a frightful amount of downtime every week. In trolling through the server error logs, I kept seeing references to other sites on the server…other people’s accounts. I eventually determined that another account on the server was inducing most of the problems.
BlueHost support was generally good about bringing the server back online after a fault. But I was seeing far too much down time…even for a very cheap hosting service. In frustration, I eventually decided that I was done with shared hosting…it was time to move to something more private. Happily, I was only a few months away from the end of a two-year prepaid hosting agreement.
Researching web hosting a bit, I found that there are various forms of private hosting, from a dedicated server to semi-private, where a limited number of accounts share a server. A dedicated server is costly, and beyond the scope of my requirements.
Semi-private seemed like a possibility, but still carries a considerable price. The most interesting, and seemingly applicable type of host was a "virtual private server" or "VPS".
A VPS is a virtualized instance of a server on a shared hardware host. Unlike my old shared host, virtualization ala VMWare, KVM or Xen is used to give you what looks & feels like your own server. But it’s actually just one of a handful of accounts running on a big, robust, hardware platform.
Since each account runs it own OS, MySQL, PHP, etc., they are effectively separated. Erroneous settings made in your VPS will usually not impact other accounts on the hardware. You get root access to the OS and can tune, or even reboot your VPS at will.
VPS-based hosting also scales easily. You simply purchase more of the hardware resources of the machine on an as-needed basis. The underlying VPS software manages access to hardware resources. You can easily add more CPU power, more memory or more storage as you need it.
Perhaps best of all, a VPS is relatively affordable. It costs more than the cheapo shared hosts, but far less than even a lowly spec’d dedicated server. This seemed like a great solution to my needs.
In Spider Man, Peter Parker’s uncle said, "With great power comes great responsibility." This is good advice to give anyone moving from a shared hosting environment into a private host. Whether real or virtual, this host is all yours. That means you must perform all the admin tasks that are typically done by sysops at the cheapo hosting providers.
When a MySQL update comes down the wire. you must install it and see that the site comes back online. Apache updates this week? Same thing. Hackers bombarding you from EC2? You have to take steps to keep them from compromising your server. There’s a lot more maintenance to be done when the host is your own.
You can pay someone to perform all these maintenance tasks for you. For some, "managed hosting" is the best plan since it lets you get back to writing, which is why you have the blog, after all. In my case, I was hoping that I could count on the help of some Linux-savvy friends to guide me as I learned to DIY.
This brings me to the end of Act One, and sets that stage for Act Two, where our intrepid non-hero stumbles through an alphabet soup of TLAs, SLAs, VPS and OSS before eventually screaming WTF!