Overselling and Resource Usage
From Site5Wiki
Site5's business strategy is to provide high quality hosting with lots of features and resources at a low price point. Those three things may, at first, seem irreconcilable, however, as Site5 CFO Kevin Hazard explained, they are not. This article outlines our stance on the issues of overselling and resource usage limitations. It is important to note that although the article refers specifically to the "$5 Deal" shared hosting plan, the majority of the discussion applies to our other services as well.
Please feel free to use this article's discussion section to ask questions and leave comments. I will be happy to expand the article to cover any topics not currently addressed.
--Matt Lightner, Site5 Co-Founder and CEO
Contents |
Is the $5 Deal Legitimate? Is it Possible?
The wild success of our "$5 Deal" shared hosting plan has led some to wonder how realistic the offer is. After all, with its 55 GB space, 55 domain pointers and 5 terabytes of bandwidth, it's a screamin', one of a kind deal. In particular, the plan's 5 TB bandwidth quota has garnered some attention, as it is, admittedly, a lot of bandwidth. If the average site we hosted came even close to using this much bandwidth, we would have to increase prices tenfold. Fortunately, for reasons well explained by our own Kevin Hazard and, in addition, by one of our competitors, that's not going to happen.
How Much is 5 Terabytes/Month?
How much bandwidth are we talking about, exactly? Let's do some quick math:
| Terabytes (TB) | 5 |
|---|---|
| Gigabytes (GB) | 5,120 |
| Megabytes (MB) | 5,242,880 |
| Megabits (Mb) | 41,943,040 |
You would need to transfer 41943040 megabits of data per month to reach 5 TB. Why convert to megabits? Because
ISPs measure bandwidth in units of megabits per second (abbreviated Mbps). To convert to this unit, you calculate how many megabits per second your site would have to transfer, on average, in order to reach 41,943,040 megabits in a month (30 days).
| Period | Megabits Per Period |
|---|---|
| Month | 41,943,040 |
| Day | 1,398,101 |
| Hour | 58,254 |
| Minute | 970 |
| Second | 16.2 |
Is 16.2 megabits per second a lot? Yes, it's a ton. Even if you're buying bandwidth en masse, 16.2 Mbps could cost anywhere from $300 to $3000/month, depending on quality and location. That doesn't even take into account the fact that your site needs the ability to burst well beyond 16.2 Mbps. Chances are that throughout the day your site's usage would range between 5 Mbps and 30 Mbps. With this usage pattern, you would be paying for a connection of a little bit less than 30 Mbps (since you pay for your max, or more specifically 95th percentile, usage).
Even if we doubled the price of this plan to $10/month and cut the bandwidth allotment by a factor of 10 (to .5 TB), we would still be losing money if someone used all their bandwidth--a fact we were well aware of when we designing our plan structure. What makes this pricing possible is that, on the whole, we come out ahead. Purely from a cost standpoint, we are able to provide 5 TB for $5/month and still make money, since the many people who use very little bandwidth counterbalance the few who use a lot.
Beyond Bandwidth
Our willingness to pay for 5 TB of bandwidth per month isn't in question. The real issue is whether it's even possible for a server to serve that much data. The answer, in the case of shared hosting, is that it's most often not possible. That being said you can definitely use a lot--at least as much, if not more than would be possible with most shared hosting providers.
In reality, only a server and site specifically designed and optimized for serving this volume of data would be capable of such traffic levels. The bottleneck is not the speed of the network, nor is it speed of the server's uplink to that network, nor is it the speed of the network interface card in the server, but rather it is the server's ability to process requests quickly enough to support such high traffic levels. The primary culprits are disk I/O and CPU availability.
Disk I/O
A hard drive's input/output rate (or "disk I/O") is the rate at which it can read and write data. In nearly all web server environments, disk I/O is the chief bottleneck. This isn't because the servers aren't using fast enough hard drives--to the contrary, our current hard drive setup provides an impressive amount of disk I/O compared to other hardware configurations. But, given the nature of the work that web servers do, it is generally the part of the system that gets maxed out first.
A web server's job is to serve stuff. Insightful, I know. But really, that's what it does all day long: send files to web site visitors, display the contents of email inboxes for hundreds of email users, respond to database queries for hundreds of scripts running on the system. Almost everything a web server does involves reading from and/or writing to the system's hard drives. And considering that it has requests for data stored all over the drive, and that there are often hundreds of gigabytes of data spread across those drives, it's no wonder that they're one of the busiest parts of a server.
Almost every job processed by a web server requires that some piece of data be read from the hard drive. That means that if the hard drives are already busy, that job can't be processed yet; it sits in the system's processing queue and waits for the requisite data to begin processing. Chances are that a site serving up 10-20 Mbps of data is going to require a lot of information from the hard drives: perhaps PHP scripts needing to be run, perhaps data from a mySQL query, or perhaps simply an image or other static file. And, what's more, the site is hosted on a server shared with other accounts--all of which also need to retrieve data from storage.
Moreover, bandwidth usage is rarely if ever constant throughout the day. Depending on the nature and target audience of a site: its traffic will peak at some times and subside at others. This means that at certain points throughout the day, the site may require much more data from the drives than if it were doing 16 Mbps. During these times, the disk wait could potentially get bad enough to drive the number of waiting processes up into the hundreds and slow sites to a crawl. Even worse, it could get back enough to cause the server to lock up and require a reboot. And, if no action is taken after the reboot, the same scenario will likely reoccur. This is clearly bad for everyone hosted on the server.
Processor (CPU)
While disk I/O is perhaps the most common bottleneck, processor (CPU) capacity is also a large factor. Shared web servers have lots going on at any given time. Every time a request that comes in, every time a script must be executed, every time an email is sent and every time a database is queried the server to do some kind of processing. Since there is only so much processor time available on a server, that server's ability to respond to requests is fixed. If a server's CPUs are unable to keep up with the number of jobs that need processing, the jobs are held in the processing queue. If the processing queue starts to back up, the system will become increasingly sluggish and ultimately, in many cases, require a reboot. This, again, is not good for customers hosted on that server.
Bottlenecks Are Unavoidable
All systems, from computers to assembly lines to a kitchen in a restaurant, are limited by their slowest resource--even if that resource, when compared with others of the same type, is fast. In the case of web hosting servers, the limiting factor is much more frequently disk I/O or CPU power than it is bandwidth. The only way to avoid hitting bottlenecks is to ensure that servers aren't overcrowded--a principle which we take very seriously.
We want to make it absolutely clear that resource usage "bottlenecks" are not the result of Site5 choosing mediocre hardware or irresponsibly overloading our servers. Our servers use top of the line hardware: lightning fast, fault-tolerant RAID drive arrays and dual top-of-the-line "dual core" processors. Furthermore, we recently implemented a system that assigns point values to each account type and monitors the number of "points" hosted by each server in order to ensure that servers remain below their capacity. Keeping servers "underfilled" provides our customers' sites with ample growing room, and also helps to accommodate usage spikes if they occur. As an example, we make every attempt to ensure that our customers' sites will stay online if they are seeing large traffic spikes, as might occur if a site gets featured on Digg or Slashdot (see Wikipedia's entry on the "Slashdot Effect").
How Site5 Deals with High Resource Usage Sites
If a server does experience higher than normal load, as they will on infrequent occasion, Site5 systems administrators use a variety of metrics to quickly pinpoint the cause. In some cases the cause is transient and not part of a larger pattern or problem. In other cases, however, the load is caused by a specific user consistently using more than a reasonable share of the system's resources. Obviously our systems administrators have some leeway in deciding what constitutes "reasonable" resource usage, however they are expected to act benevolently. We don't go out of our way to attract new customers only to ask them to leave.
When we encounter a site with high resource usage, we always work with the site owner to help them identify and address the root cause as quickly as possible. In some cases, however, we are regrettably forced to temporarily disable a site (or part of a site) in order to prevent a server from becoming unstable or slow. If this happens, we immediately notify the site owner and inform them that we are standing by to offer assistance. All tickets relating to these temporary suspensions are placed in a separate ticket queue which is given absolute top priority (in fact, it's named the "Urgent Queue"). Our goal in these cases is to find a solution that doesn't require the customer to move their site; customers don't want to change hosts any more than we want to lose their business. In fact, as I type this, we are in the process of moving a customer's site to an empty server--essentially giving their site its own private machine--so that we can keep it up and running while we work with the owner to address resource usage issues.
When working with customers, we will try to help you track down the cause of your site's resource problems. In some cases, the issue can be fixed relatively easily, perhaps by adding an index to a database table or enabling static page caching. In other cases, the solution is slightly more involved and may entail modifying your site to use more efficient software, or optimizing code yourself. But there are times when there is no simple solution for reducing the amount of resources a site uses. Sometimes a site has simply outgrown shared hosting (which is good, as that indicates it's probably successful!). In these cases, we will recommend that you look into a more robust hosting solution--perhaps a VPS or dedicated server.
Resource Usage: A Shared Hosting Reality
Resource usage is a reality of shared hosting, as the term "shared" implies. There's a reason you pay $5/month for a shared hosting account, rather than the $1-500/month price of a dedicated server, even though the space and bandwidth allotments are often mildly comparable. You're in an environment with other customers, and that carries with it certain restrictions and responsibilities. You can't manage your site with impunity, and you can't expect that, under all circumstances, you will be able to max out the bandwidth allocated to your account. There are other, more significant--albeit less tangible--limitations that can be and often are reached first.
Perhaps the most important thing to remember is that the 5 TB bandwidth quota is not, by any stretch of the imagination, to trick customers into thinking that they can host any site under the sun on our servers for $5/month. It should not be seen as a guarantee that you will be able to push 5 TB of bandwidth per month on your shared hosting account. Even on many dedicated servers, unless your site is properly designed and optimized, you probably wouldn't be able to use that much bandwidth. You should see the 5 TB quota as more of an indication that bandwidth will probably not be a primary factor in determining whether your account belongs in a shared hosting environment. Similarly, many providers offer unmetered bandwidth, meaning that they don't even bother tracking sites' bandwidth usage. But you can be certain that their lack of a hard bandwidth limit is not tantamount to a claim that their shared hosting accounts are suitable for hosting any and all websites. To the contrary, it is a very good indication that they use other factors to determine whether a site belongs on a shared hosting account.
Once again, our motivation for choosing such a high bandwidth limit was, as described above, to indicate to customers that we're not overly concerned about your site's bandwidth usage. To make the assumption that because we are not concerned about bandwidth usage that we are not concerned about any of your site's resource usage would be a logical fallacy.
As a shared hosting provider, we have a responsibility to ensure that all sites have access to their fair share of the server's resources when needed. The fact of the matter is that some sites just don't belong on a shared hosting account, and we would be remiss in our duties if we allowed them to remain on our servers. You can expect any responsible hosting provider to do the same.
Related wiki pages: Measurements Guide; Resource Usage Policies
