Bandwidth Limiting Policies for Web Hosting?

Silas asks: "I run a small website development and hosting company. We're trying to develop creative, fair, but standard policies in limiting the bandwidth of our individual hosting accounts. I seek the opinions of Slashdot readers who have experience as hosting providers or hosting users. More details below. We're running Apache, and have pretty much decided on using mod_throttle as our bandwidth limiting technology. I know it's not everyone's favorite, but it looks great for us. We have less than 200 domains being hosted, all with varying degrees of bandwidth requirements. As you might suspect, we've got our own ideas and have done our own research about the answers to these, but now I'm interested in yours."

"The basic question is 'what's fair and standard' in these areas:

• Our two hosting packages offer 5 GIG/month and 10GIG/month respectively, with the option to upgrade in $5 per 1 GIG/month increments. Other hosting providers seem to be all over the board - what's the average hosting account want/need?
• The policy that seems common is 'allow a certain amount of data to go through in a certain time period, and then start rejecting requests until the end of the time period'. Is that fair? What policies do other hosts use? When is it appropriate to delay the response to a request instead of rejecting it?
• What should the user be able to do automatically in terms of upgrading/controlling their bandwidth usage? If a user is fine with 5 GIG/month but then gets slashdotted, what should their options be (right away, within 24 hours, etc.)?

We know we're not a powerhouse hosting company, and we know we can't compete with the big players in this industry, so please avoid comparisons/critiques based solely on price points, as we'll likely never be able to match the bulk hosters in that area. We're focused on excellent customer service and convenience to our design clients."

My solution

[Trusty Penfold]

If referer=slashdot.org then throttle=99% else throttle=10%

Re:My solution

[MattCohn.com]

Now, there is some truth in this. I would moderate +1 Insightful but I thought to just comment instead and let other people mod. There was a story (I can't find it) where slashdot linked to a site hosted on a shared server, and the owner of the site posted an e-mail from his hosting company basicly saying "Sorry, buh-bye". They did make a good point, that the server had crashed over 4 times that day... but it seems like since it was already over canceling the account was pointless.

I would think that if you set up creative policies, it should allow for DOS-like conditions as long as they were one-time, and not the fault of the site's owner. Now I'm not trying to flame/troll slashdot, but I'm quite sure the continued reckless linking will continue for the imediate future, and I would hate to be a site owner talking to an IT department after a mid-day slashdoting.

I'd LIKE a cap on my accounts.

[zulux]

If I could set a cap on some of my accounts - I'd like it: I woulden't get a huge bill at the end of the month for over use if any of my sites got 'slashdoted.'

Re:I'd LIKE a cap on my accounts.

[LordNimon]

Yes, this is very important. You should give the user the opportunity to have the site shut down if it hits is bandwith cap. For personal web pages, it doesn't really matter if the site is up or down, but the overcharges can be very painful. I once had an $80 bill one month because I happened to put up a large web page that was very popular. I could have moved it to another site, but I didn't realize what was going on until I was over my usage. Bastards didn't even bother to email me!

Re:I'd LIKE a cap on my accounts.

[irc.goatse.cx troll]

Mod_Throttle [snert.com] is exactly what you need. It can be configured to limit to N kb/month, and also has a verry nice status page showing you how many hits each vhost is getting, and how much bandwidth usage they are using. Highly recommended.

Huh?

[Anonymous Coward]

We know we're not a powerhouse hosting company, and we know we can't compete with the big players in this industry, so please avoid comparisons/critiques based solely on price points, as we'll likely never be able to match the bulk hosters in that area. We're focused on excellent customer service and convenience to our design clients.

Now how exactly does it relate to the question about bandwidth throttling? Why is it necessary for you to point out that your prices are not the best in the industry? How does your pricing strategy relate to bandwidth consumption control?

Re:Huh?

[the_greywolf]

he's asking what kind of a bandwidth strategy is good with what pricing strategy, not just what to use to manage the bandwidth.

Re:Huh?

[Silas]

Now how exactly does it relate to the question about bandwidth throttling? Why is it necessary for you to point out that your prices are not the best in the industry? How does your pricing strategy relate to bandwidth consumption control?

Because, one possible answser to my inquiry might be "lots of hosting providers these days offer unlimited bandwidth. Why can't you do that?" or "You charge too much for bandwidth as it is!" While those may be valid answers, I wanted to clarify that we're not operating on a scale where we can make those sort of adjustments as easily, and so I'm interested in answers that focus on managing existing resources better instead of conforming to what may be standard for the big powerhouse hosting companies. I hope that helps.

Put it to the users

[__aafkqj3628]

I would set it up so the users have the option of "after 5gig, ignore requests" or to start paying for extra bandwidth at the normal rate (to a certain point/unlimited).

Policies

[coene]

I cannot speak to the cost of bandwidth, which is one of your concerns.. However -- there are a few simple things that customers really like:

1) Automatic cut-off. If a customer has 5GB/Month, and cannot afford more, make sure their site goes unavailable and they are not billed. You do NOT need to continue service, they understand! Just make sure point 2 is made...

2) Notification of cut-off. If above customer runs out, they want to know! Make sure they get an e-mail, but more preferrably a call. It's important, very important!

3) Options for automatically extending the plan. Make sure that customers have the option to have their bandwidth upgraded (of course at additional cost) automatically. This is something a lot of customers will ask about, the type of customers who never want their site to go down, regardless if it costs them. Many customers think "More traffic, more profits", and if their site goes down due to exceeded bandwidth usage, they will think its your fault.

4) Be upfront with all of these issues. Many providers arent verbose enough with customers, and it ends up with them being confused. By laying it all on the table, they will see the above strategy and they will like it. It gives them options that are very important.

Re:Policies

[jhines]

Notification, when the site hits like 80% of usage would be great as well.

Re:Policies

[jon doh!]

i'd also say go for a notification if the usage suddenly jumps. if so, maybe the site could throw up a less bandwidth-hogging page, simple text or even a link to mirror sites or something.

Re:Policies

[Gerry Gleason]

That's exactly right. Flexible policies taylored to the individual customer's needs, and good communication when (ideally, before) the limits are hit. Some customers would love to be slashdotted as long as their site can scale to handle it, they want all the page views they can get. If you could be hitting the limits of your system resources as well as bandwidth during a traffic peak, then you are also going to have to take care that one customer spiking doesn't take out the rest that are sharing some other resource.

Also, ask your customers what is most important to them. It will vary, and you will find out what to spend your time and efforts on to make them happy.

Up the Bandwidth!

[Antilime]

I think your sites could be given a bit more bandwidth. If they decide to host one .exe file on there of any size at all (not sure why they would, but just for example) - you are looking at that bandwidth going in a few days. I host gaming files and that would easily be used up.

Throttling simply does not work

[Electrum]

We [itmom.com] gave up on throttling. It just doesn't work. And not from a technical standpoint, either. If you are going to do throttling, then you need a web server that does real throttling. The only one I know of is Zeus [zeus.com]. It does real throttling, letting you limit the total bandwidth for all of a user's sites to a bytes/sec value. No Apache modules do this. Even thttpd [acme.com] doesn't seem to get this right.

I assume that you want to limit bandwidth that your customers use because the bandwidth to your server(s) is limited (i.e. you don't have a 100mbit connect to the internet). In this case, Apache modules will not do what you want. Someone puts up a 10mb file. That file gets downloaded and uses up all of your outgoing bandwidth. While it is being downloaded, the Apache throttle module refuses other requests. This is obviously not what you want.

So suppose you end up using Zeus, or find some other way to do real throttling. Now what do you set the throttle speed to? 5gb over a month averages a little less than 2k/sec. Say you set it higher, like 20k/sec, and there are ten connections downloading that user's files (which can easily happen with certain browsers). What does the average clueless user or webmaster think? They don't understand throttling. They just think that the website is slow and that your service sucks.

We would throttle down user's sites when their bandwidth ran out. Customers did not understand that they had run out of bandwidth, even though they were notified via email. They just thought their sites were slow. We received a lot complaints about that.

We found that the best thing to do is to not throttle and to presell bandwidth cheap. Our different packages come with different amounts of bandwidth, ranging from 5gb to 180gb. After that, customers can purchase extra bandwidth (for $0.50/gb). Customers receive a notification via email when their bandwidth is running low and again when it is completely gone. When their bandwidth is gone, we redirect their sites to a page stating that they used up all their bandwidth.

This solution is simple and it works. Customers always know how much bandwidth they have left and can buy more at anytime. We never have to worry about users running up a huge bill and not paying it, since everything is prepaid.

Re:Please tell us HOW you did this!

[Electrum]

How exactly did you go about setting this up? Can you go into details?

It's really not that difficult, if you have a good hosting setup. Our hosting system is designed to be 100% automated, all controlled from our custom written control panel.

We use Zeus' virtual server feature. Every customer has their own virtual server. In Zeus, everything is a virtual server. There is no concept of a main server like in Apache. Thus each virtual server can have its own configuration and be independently controlled.

Each virtual server can have subservers. Subservers is similar to Apache's mass virtual hosting (but better). A virtual server has a subserver directory, which is a directory full of symlinks with the name of the site hostname, pointing to the site content directory. When a customer runs out of bandwidth, we simply place a .htaccess file (Zeus mostly supports these) with a redirect line in the root of the subserver directory. Due to the directory layout, customers do not have access this directory.

If I had to set this up under Apache (ick), I would use the mass virtual hosting [apache.org] module. The virtual host directory would be full of symlinks with the name of the site hostname, pointing to the site content, as with Zeus. The difference with Apache is that all sites for all customers would be in one directory. Apache configuration is much more messy and not easily scriptable. To redirect the disabled sites, the symlinks would be changed to point to a different directory.

Accumulating bandwidth statistics for this can be done in different ways. We use a custom ISAPI module which sends logging info through a socket to a daemon which accumulates statistics and periodically saves them to a MySQL database. Doing a SQL query for every web request would not work.

For Apache, a similar module could probably be written. Or server logs could be processed. Logs could be written to a pipe and the process on the other end could accumulate bandwidth and other statistics (or write out logs for something like Analog to process).

A script runs from cron that processes the bandwidth statistics in the database. It updates the bandwidth counters in the database for the user, making it easy to see how much bandwidth is left from the control panel. When a customer is low or runs out, the script sends a notification email. When the customer is out of bandwidth, the script updates a table which tells the backend hosting daemon to actually disable the sites. After the customer buys more bandwidth, the script updates the table telling the daemon to enable them again.

(Hint: SQL databases are a very nice way to let daemons on different servers communicate with each other.)

Re:Throttling simply does not work

[dagnabit]

> It does real throttling, letting you limit the total bandwidth for all of a user's sites to a bytes/sec value. No Apache modules do this. Even thttpd [acme.com] doesn't seem to get this right.

FYI, the Sun Cobalt [sun.com] RaQ appliances allow you to set througput limits in kilobits/second (low=10, high=??) per IP address (that's for all IP traffice - FTP, HTTP, mail, etc), known as "Sun Cobalt Bandwidth management"... (It's done via a kernel module...) No auto-cutoff after x GB/time period though, just setting the pipe size...

Re:Throttling simply does not work

[WickerChap]

Our company uses "Packeteer", which is an excellent solution for tuning bandwidth. Each type of connection can be assigned a class (inbound SSL, outbound corporate HTTP etc) and can be throttled accordingly. good reporting, too.

Simple solution

[infonography]

Wirecutters, you can reduce all sorts of bandwidth. Throttling just loses you customers who do want to grow.

Seriously, your a small outfit, if you meter the client's usage you can charge accordingly. Write it into the contract about how much you charge.

If you somehow get a spammer or a Warez site, they make themselves quite obvious if YOU AEW paying attention to bandwidth, have yourself paged when a user exceeds a certain amount and look at what they are doing.

If they got slashdotted, fine, but if your seeing a lot of SMTP going out or large files getting downloaded yank them quick. Upstream vendors don't care about what's coming into your sites, it's what's going out that they charge you on.

mod_throttle..

[stevey]

I tried to setup mod_throttle for a site where the requirement was 'No more than 1gig per hour'.

I actually found this incredibly hard to do, it's fine for slowing down the incoming requests when lots of them start coming in, but hard to make it keep track of total traffic served.

I think it should be fairly straightforward using the 'volume' directive, but I could never quite get it to work out properly.

My solution was mod_curb [freshmeat.net] which is dedicated to just doing that. (It doesnt handle virtualhosts yet, but it will do by next weekend.

My experiences from a user perspective

[beebware]

Personally, I run a high-bandwidth site and have had a few qualms finding a host. I've now settled on Positive Internet [positive-internet.co.uk] here in the UK because of their 'fair' bandwidth/process usage policy. Basically, they have no 'fixed' limits - therefore if your little site gets slashdotted one day (or, as mine did with my previous host, get featured on national television) and has a 'spurt' for a day or so, then they won't mind. But if (as I eventually ended up doing) you consume a significant part of their bandwidth/processor usage (I was constantly in the top 10% on one of their shared servers - and this is for months on end), then they contact you and offer you a 'more suitable product'. I've now got my own dedicated server hosted by them (and, therefore, can eat up as much processor usage as I like), and they'll inform me if I eat up massive limits of bandwidth.
What I guess I'm practically saying, is try for 'soft-limits'. If you have a 'hard limit' of 5Gb/month and someone uses up 5.01Gb in a single month (previous months were less than 2Gb) - would you want to loose their custom? Ok, if the next month is also 5.01Gb (or higher) - then it's "contact customer" time - but just "arbitarily shutting down sites" is, IMHO, not a good idea (unless, of course, they are causing _significant_ harm to your business: ie saturating more than 60% of your pipe on their own - but you should have really noticed that before hand _or_ check the source of the referers: it may just be a spike for an hour or two due to slashdot or similar).

Calculating monthly transfer needs ... help!

[wessman]

If the average developer website hosting package offers 10 gb (10,000 mb) of monthly transfer and the average webpage weighs .1 mb (100 kb), hypothetically, the following equation gives the account's maximum allowable pageviews per day: (10,000 mb max transfer/month / 30 days) / .1 mb average download size = 3,333 max hits/day given text-only files and no uploading. Besides the consideration of graphics, linked scripts, and uploads, is there any fault in that equation? Do web server packets affect the total number of pageviews the account can handle? It just seems to me that just over 3,000 hits/day would not be enough for a small, but popular website, like a mama/pops storefront or a band homepage, for example. I mean, how would Slashdot's daily pageview count compare to its monthly transfer rate given that equation? How do Slashdot reader websites hold to that equation? Do any experienced sys. admin. here have a better equation to evaluate an account's max allowable pageviews per day? This is obviously an important consideration when building a website for a small organization, an up-n-coming artist, or a personal website.

Let others buy bandwidth as well

[printdevil]

I'm not sure who your customers are, but one thing I've often wanted when a site is slashdotted is the ability to buy more bandwidth -- if it were cheap ($1-2/GB), I'd pay as a reader. Not sure how hard this would be to implement, but it would be nice.