How To Choose A Hosting Plan

You’ve certainly asked yourself a question along these lines at some point:

I’m setting up a site that I expect will get 1,000 or so visitors per day. Should I use a shared hosting plan? If so, which hosting package should I get?

In what hopefully are layman’s terms, here goes…

What The Figures Hide In Practice

1,000 visitors per day is in fact relatively few. The real question is what the figure hides. Not all sites have the same requirements for a similar number of visitors.

Let’s assume, for the sake of giving pointers, that these 1,000 visitors per day are evenly distributed throughout 10 peak hours. It’s a reasonable assumption for the sake of modeling. Let’s further assume that visitors load 12 pages on average — it’s gargantuan by any blogs’ standards, but let’s stick to that in order to account for robots. And that page views conveniently occur in tight bursts, every 15 seconds — allowing us to account for traffic peeks.

In the end, we’re talking about 1,200 page views per hour. 20 page views per minute. 5 concurrent pages views per burst. 15 seconds to deal with each burst.

Spelt out this way, and assuming html files that your web server will serve instantly, the obsolete desktop in your attic will handle the load without a hiccup. If we assume WordPress with mountains of plugins enabled instead; and one second to generate a page (huge!)… my laptop would manage. As would your desktop. Or any shared host, for that matter.

You’ll want to keep an eye on a few things, however.

Things That Can Slow Your Site Down

Setting aside the obvious, i.e. hosting your site on a server shared by more users than is reasonable, quite a few things that can slow a site down.


Ever heard Java was slow? Sit tight. php is about 50 times slower. Of all of the web development toys I’ve tried, only Ruby on Rails was slower. (Rails is the bloated part, not Ruby.) It’s a lot slower to generate a dynamic page using php than it is to generate the same page using C++. And both are slower than serving static HTML files.

Then again, costs count too (cheap php hosts are ubiquitous), php is seldom installed without Zend Optimizer or equivalent, we’re not generating complicated Mandelbrot sets, and WordPress, which is our topic of interest in practice, does not use bloated libraries available in PEAR. Plus, there’s WP-Cache. Next…

Pages That Include Multitudes Of Files

The equation here is reasonably straightforward: Every dependency in your page, as in every CSS file, javascript file, image file, and so on… is one more hit that your web server will need to process.

Then again, we’re merely reading a file, so it’s not an expensive hit, and a lot of this will get cached by browsers and ISPs. They’re still hits, and a subset thereof can turn into trouble.

Large Media Files

When Google bought it, YouTube had no credible revenue stream, and expensive trials with Hollywood majors coming up. Of higher interest to us, they were also spending mountains of cash on storage and bandwidth.

Shared hosts invariably loath sites that generate hundreds of large file downloads, because:

  1. Users who binge on audio and video files can gobble up gory amounts of bandwidth.
  2. Large file downloads are concurrent hits that can span several seconds, even minutes.

The two combined can slow a server’s response time quite a bit.

For the sake of explaining what happens in very simplistic terms, suppose 5 users start downloading a 10M video at the same time — each completing the task in exactly one minute. Now, add 5 more users every 15 seconds, and suppose that 20 concurrent downloads slow things down by a second for each user, no matter how far they are from completing their download.

At 45 seconds, we’ve 20 users. At 1 minute, when 5 new ones start, the initial 5 are a second away from completing their download. We’ve a total of 30 users. Without the extra latency, we’d have 20. Getting a feeling of where we’re heading? Great! Things aren’t that simplistic in reality, but the general idea remains valid.

Thus, consider hosting your large video files on sites like YouTube. The latest version of Mediacaster will let you easily do so.

In the rare event you really need to host your files, you’re still safe to start out with an entry-level plan. By the time infrastructure will be of any concern to you, you’ll have the revenue stream to cover its costs. Next…

Database Calls

Don’t get me wrong, database queries are extremely fast. Were they not, everyone would be using flat files instead. The one thing that can and will slow your site down are those busy SQL servers located at the other end of the data center. Everyone in the facility seem to hitting them all the time. Two reasons.

On the one hand, software developers in general, and php framework developers in particular, erroneously assume databases are huge arrays — and query them accordingly. I’ve yet to find an open source CMS that implements things an SQL junkie would take for granted, such as pre-indexed trees.

On the other, MySQL (ubiquitous in open source software) featured no sub-query statements until very recently. As I’m writing this, MySQL 6 is available for download, yet hosts routinely install MySQL 4. Data that ought to be retrieved in a single round trip get retrieved in zillions of them instead, and MySQL servers turn into bottlenecks.

Luckily, two workarounds are easy to implement:

  • Use an advanced cache, such as WP-Cache, to reduce the load on the MySQL server.
  • Install MySQL on your own virtual private server.


RSS Feeds

Offering an RSS feed is akin to setting up a distributed denial of service (DDOS) attack on your own site. (In case you’re wondering, hackers extort protection rackets from Jamaica-based poker sites by making their sites unavailable using DDOS attacks: Massive numbers of requests from multitudes of sources.) The issue at hand goes down to how your subscribers (real or robots) behave:

  • Some will be using feed subscription services. These generate negligible traffic, since the feed gets cached for entire groups of users.
  • Others will read your feed using a desktop reader. Each of the latter will hit your site all day with painstaking regularity.

In my early days of blogging, I sincerely hated one of my subscribers. He was hitting my RSS feed every few minutes; 12 hours per day. He was gobbling up 150MB of my overpriced 8GB per month hosting plan. It’s laughable in retrospect; but at the time I felt very happy when whoever that was unsubscribed.

Anyway, here too, there are workarounds. In the best of worlds, you’re using your site’s normal feed url, and FeedBurner is dealing with your 150MB per month subscribers — and delivering stats as a bonus. Last…

A Server Far, Far Away

A quick note on this point in case it isn’t obvious to someone. In today’s globalized world, it’s trivial to host your site wherever you want. Give it second thoughts as there are two flip sides.

To start with, your site’s average response time can suffer tremendously:

  • A 30ms round trip delay (a server at the other end of your home town) feels instantaneous.
  • A 150ms round trip delay (New York, Los Angeles, and back) is noticeable.
  • A 300ms round trip delay (New York, Singapore, and back) is borderline unbearable.

Then, consider what happens if your English site has an IP address that belongs to a cheap Thai host: Google treats it as a Thai site, and offers its results to locals who decide to “Search Thailand”.

In the end, the closer your site is to the bulk of its visitors, the better. And unless you’ve good reasons not to, have it hosted in the country of your target audience.

So… What Do I Need?

In the short run, much about any basic plan will be fine for a new site, provided the WordPress requirements are met.

In the long run, the only thing of real importance will be the support you’ll get. For this reason, you’ll find a few recommended hosts on this site.