Running WordPress on a Budget Slice.

When we created the Full Stop website, I researched the best hosting available and landed at Our requirements were minimal (a one page site using HTML, Javascript, CSS, and Flash), and NearlyFreeSpeech had a beautiful model: only pay for what you use. ((They also have unbelievably good writing, particularly in the FAQ. Ex. “Why doesn’t your website look like other hosting provider sites? It’s simple. We don’t want to confuse people into thinking we’re anything like other hosting providers. Our simple, text-based layout is designed to load fast, to be easy to use, and not to try to distract you from making an informed decision about us.”)) Until clients started beating down our proverbial door, we would be hosting our site for pennies each month. Talk about bootstrapping.


The first hint of a problem came when I wanted to optimize the files visitors were downloading. The easiest way to compress those files is to tell Apache to do it each time someone visits the site. I like that because it makes the page load faster and costs me fewer pennies since fewer bytes are being used. NearlyFreeSpeech doesn’t like that because the server has to work to re-compress the files each time rather than me, the developer, compressing them once and simply hosting the static files. So they don’t allow it. I can’t blame them, and that’s not a problem for one page and files that rarely change. It became a problem, however, when we decided it was time to saturate the world with subliminal messages to work with us through something the kids are calling a “blog.” ((You’re reading it.))

I spent the better part of a day researching hosting. ((I have a problem. When I was buying a $15 flashlight for camping, it took me almost 10 hours. Do you have any idea what kind of ROI that is?)) The options appeared to be shared hosting, grid hosting, or a virtual private server. As we pretend like we’re running a business here, no shared host was going to cut it.

Next I took a hard look at Media Temple’s Grid-Service. I have to say, it was awfully tempting. A lot of the big guys use MT, and it has a good rep in the design community. It had everything else we were looking for too like a nice control panel, the latest LAMP builds, version control, scalability, and for $20 / month, it wasn’t going to break our piggy bank. But. I had a few nagging feelings. We had used (gs) on a previous project. I wasn’t blown away by the performance. Letting someone else manager our “server” would be convenient, but was it flexible enough? Would it allow us to really optimize the system? What about all those people who were complaining, or the frequent outages on the status blog? I suppose that’s inevitable, but it still left me uneasy. Hmm.

That left virtual hosting. Plenty of companies offer virtual hosting, but none has the reputation of Slicehost. ((Referral link. I don’t expect you to sign up, but if you do (and stay with them for three months), we get some kind of kickback. I don’t even know how much it is. )) When I’m buying anything, I look for the brand that people love. You might find a lot of people who run Windows on their computers. I haven’t met one who loves Microsoft. The praise for Slicehost is deafening. The critics are silent. That’s what I’m talking about.

There was one nasty hurdle to clear, however, if we were to sign up for Slicehost: I’ve never done more than install Ubuntu on a spare laptop much less configure and maintain an entire server. If you’ve lived in the world of shared hosting your whole life like I have, running your own server is a big, scary leap into the unknown.

So we cheated.

The Part About Setting Up the Slice and Running WordPress.

We called in some help and set up a basic slice with the latest version of Ubuntu (9.10). (Ubuntu Server Guide.) Then we quickly installed Apache, PHP, and MySQL. Everything worked perfectly. It was fast, really fast. Until someone visited the site. Crash.

After a bit of trial and error, we discovered that the default Apache and PHP settings aren’t intended for use on a cheap virtual server with only 256mb of RAM. Each session that opened continued indefinitely, hogged as much memory as possible, and eventually ran our little slice right into the ground. Good thing Zeldman hadn’t linked to us yet.

We tweaked our settings ((Take a look at “Configuring a Lightweight Apache / MySQL Install on Debian / Ubuntu” and “Introducing LAMP Tuning Techniques” via this thread on Slicehost’s forum.)), and got ourselves back the game. Until we opened the site one Sunday evening to discover it wouldn’t load. A restart put things aright, but this had gone far enough. It was time to do something drastic, so we ditched Apache and found a server more our size: nginx (pronounced “Engine X”). Nginx is svelte where Apache is, ahem, showing it’s age. Getting everything set up wasn’t as easy, but the payoff has been a speedy, stable site. Thankfully we were hardly the first to travel this road. Check out “Nginx ‘How To’” and “PHP and Nginx on Ubuntu: the Easy Way.”

All the steps I’ve outlined so far were for server configurations, but we didn’t ignore our code. Between WordPress’s lack of built-in caching and my awful programming, we were querying the database far too many times. Installing the WP Super Cache plugin for WordPress will solve 90 percent of that problem. It comes highly recommended.

The Road Ahead.

The experience of setting up, configuring, and optimizing our Slice alone has been worth the effort, but we’re happy that’s not the only benefit. The result is stable (we think), flexible, and feels snappy. While Full Stop isn’t absorbing the type of traffic sites like Stack Overflow do ((You won’t be seeing a crazy network diagram like this any time soon.)), the setup we’re running today should get us through the next 12 months at least.