Slashdot Mirror


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."

30 comments

  1. My solution by Trusty+Penfold · · Score: 3, Funny

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

    1. Re:My solution by MattCohn.com · · Score: 2, Insightful

      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.

    2. Re:My solution by Anonymous Coward · · Score: 0

      Maybe you should keep a track of the referring sites. If an obscene number of hits come from any referring site, throttle their speed - they're being Slashdotted/ArsTechnica-dotted.

  2. I'd LIKE a cap on my accounts. by zulux · · Score: 4, Insightful

    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.'

    --

    Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.

    1. Re:I'd LIKE a cap on my accounts. by LordNimon · · Score: 3, Informative

      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!

      --
      And the men who hold high places must be the ones who start
      To mold a new reality... closer to the heart
    2. Re:I'd LIKE a cap on my accounts. by irc.goatse.cx+troll · · Score: 1

      Mod_Throttle 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.

      --
      Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
  3. Dear Slashdot by Anonymous Coward · · Score: 0, Insightful

    Dear slashdot,
    I don't really have a problem. I use mod_throttle for bandwidth limiting and I love it. What do you use?
    Also, now I will plug my company and get some free advertising on Slashdot's front page. Actually, I paid for this Slashvertisement, but don't tell anybody that!

    Sincerely,
    SlashLamer

    1. Re:Dear Slashdot by Anonymous Coward · · Score: 0
      Clearly the truth must be silenced with a -1, Troll. These slashvertisements don't work if people discover them. Shame on you guys. You're worse than search engines artificially promoting paying customers.

      Oh wait, they need to make money to continue to allow us to speak openly. The discussion would still be of interest to many viewers. It's a win/win scenario.

      Really, comon people. This isn't a big deal.

  4. Fuck throttling by Anonymous Coward · · Score: 0

    Let the people serve all the pages they want... just charge for excess bandwidth. They get their pages served, and you rake in the $$$.

  5. Huh? by Anonymous Coward · · Score: 2, Interesting
    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?
    1. Re:Huh? by the_greywolf · · Score: 1

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

      --
      grey wolf
      LET FORTRAN DIE!
    2. Re:Huh? by Silas · · Score: 1
      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.

  6. Put it to the users by __aafkqj3628 · · Score: 2, Informative

    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).

  7. this site has a horrible deal by Anonymous Coward · · Score: 0

    csoft.net has unlimited transfer, 150 megs and half of their smallest package

  8. Policies by coene · · Score: 5, Insightful

    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.

    1. Re:Policies by jhines · · Score: 2

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

    2. Re:Policies by Gerry+Gleason · · Score: 4, Insightful
      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.

    3. Re:Policies by jon+doh! · · Score: 1

      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.

  9. Up the Bandwidth! by Antilime · · Score: 1

    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.

  10. Throttling simply does not work by Electrum · · Score: 5, Informative

    We 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. 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 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.

    1. Re:Throttling simply does not work by dagnabit · · Score: 1

      > 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 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...

    2. Re:Throttling simply does not work by WickerChap · · Score: 1

      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.

      --
      "I love deadlines. I love the wooshing sound they make as they fly past" Douglas N Adams
    3. Re:Throttling simply does not work by Anonymous Coward · · Score: 0
      Here's how to throttle every single webserver in existance, on FreeBSD:
      • Compile a kernel with DUMMYNET and IPFIREWALL
      • ipfw add pipe 1 ip from 192.168.37.20 to any
      • ipfw pipe 1 config bw 784Kbit/s
      There ya go, your site on 192.168.37.20 is now limited to half a T1.

      Throttling is very useful because customers perceive a site that always doles out 512Kbit, no matter what, as higher quality than one that sometimes shoots data down at 10Mbit, sometimes at 512Kbit.

  11. Simple solution by infonography · · Score: 2, Interesting
    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.

    --
    Sorry about the writing. Robot fingers, you know? Cliff Steele in DOOM PATROL #23
  12. Please tell us HOW you did this! by Anonymous Coward · · Score: 0

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

    TIA.

    1. Re:Please tell us HOW you did this! by Electrum · · Score: 4, Informative

      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 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.)

  13. mod_throttle.. by stevey · · Score: 4, Interesting

    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 which is dedicated to just doing that. (It doesnt handle virtualhosts yet, but it will do by next weekend.

  14. My experiences from a user perspective by beebware · · Score: 2, Insightful

    Personally, I run a high-bandwidth site and have had a few qualms finding a host. I've now settled on Positive Internet 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).

  15. Calculating monthly transfer needs ... help! by wessman · · Score: 1

    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.

  16. Let others buy bandwidth as well by printdevil · · Score: 1

    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.