11

I'm working on a web site that is likely to be very bandwidth-heavy. A major feature of the site when in active use can pull up to 1Mbps for a single session. Luckily, once users get over the new toy factor, the use of this feature will probably be 1-5% or less (probably much less) of session time.

However, new users are likely to play with this feature a good bit, especially at launch. I'm very concerned about bandwidth use.

This is more or less a niche market, so I won't ever be needing to scale to crazy levels like YouTube. However, it is entirely possible for it to be a couple terabytes/month.

Is co-location my best option? What cheap bandwidth services (colocation/hosted/cloud/whatever) are out there?

Improve this question
3
  • How much bandwidth are we actually talking (peaks), that determines your commitment level, which strongly influences if a colo is a good idea or not (given 95%tile billing being quite common)
    – Tim Post
    Aug 6, 2010 at 16:57
  • 1
    Okay, I think I'm leaning towards setting a hard limit at 10Mbps. I can have a limited beta phase. I'd start off with it wide open, and switch to limited preview accounts if I get swamped. That should work.
    – darron
    Aug 6, 2010 at 19:05
  • Very curious what type of dynamic content you are generating that requires 1Mbps to download! Live video? Anyway you might want to check out this related question: serverfault.com/questions/148629
    – Greg Bray
    Aug 8, 2010 at 18:34

6 Answers 6

Reset to default
6

A lot would depend on how many concurrent sessions you are expecting. If more then a few concurrent sessions is likely then you are going to need something that grants you a 100Mbit connection, 1Gbit if you expect more than 50.

It will also depend on what sort of resilience you require - if you must have uptime guarantees and other SLAs and/or fail-over systems to take over in case of a problem (because the project is important enough for a short period of down time to be embarrassing) then your options are more limited and your costs will be higher.

If you can separate the large data from the rest of the app then you do not need to move everything to a new hosting solution. For instance if the large bandwidth items are video files then you could rent a dedicated server with good bandwidth somewhere and host them on that - you can get servers on good hosts with decent bandwidth and 100mbit+ connections surprisingly cheaply these days (I pay $50/month for a small server with a 10Mbit link that I could saturate in both directions 24/7 if I needed to, so a 100Mbit link with a beefier server attached is not going to be expensive unless you need guaranteed uptime and other SLAs and/or server management from the hosting provider). If the server is just serving static files (even large ones) you do not need much of a machine in terms of CPU and RAM, just fast drives and bandwidth. It might also be worth looking at "cloud" hosted solutions or a content delivery network - they might be easier to scale should you under-guess how much bandwidth you need are are in theory much more resilient (so you might get a decent uptime guarantee with compensation if they fail to keep to that SLA). Keeping the bandwidth hogging action separate in these ways has the added advantage that if the high-bandwidth feature does attract enough attention to make it crawl that won't block all your other features at the same time.

Improve this answer
1
  • No SLAs, no crazy uptime requirements. It uses a decent chunk of CPU/RAM per session currently. A single beefy box should handle a good number of concurrent sessions, though.
    – darron
    Aug 6, 2010 at 18:18
1

Purely historically:
Back in the days before Facebook games, people were all in to browser based, text-format MMO's.

A relatively new one was Ogame. It was graphic heavy and a map system of 9 times 999 pages(9 universes with 999 sectors with room for 15 planets each, and each planet could have a moon).

The amount of users joining was insane and the amount of traffic even more so.

So what did they do to solve it? They started using a PHP template system and allowed users to host the images and CSS files themselves. All you had to do was click a checkbox and enter the absolute path to the base folder. They would save this in their database, use the HTML <base> element and and the template system set the URI from http://path/to/image to file:///path/to/image

After that, all the img links could stay the same. Nothing needed to be downloaded, because the users already had it. Meaning faster page-load for the user(meaning better product reviews) and also lower bandwidth usage for the company hosting the site.

And as an added bonus, they sold it as "make you own custom backgrounds and images, aren't we nice guys for letting you do this?"

Improve this answer
1

We have a high traffic site and have a lot of pictures that are loaded on each page. We have dedicated servers but decided to put the pictures on Amazon S3. It sounds like you may be talking about video files or some other type of large file which I think would still apply here. Here are some pros and cons (for us)

Pros

  • Less diskspace needed on our servers
  • Less bandwidth for our servers
  • Our log files are significantly smaller
  • We can easily integrate it with Amazon CloudFront to make the loading even faster for visitors

Cons

  • It costs a LITTLE more. We could save a little money by having it on our own servers
  • Less control over them (Amazon) going down...lucky for us, they don't really go down. :)

Other Thoughts

If it isn't media files or large file downloads that your talking about, my answer and several of the others might not make sense. Give us some more details and we'll do our best to help.

Improve this answer
0

It sounds like what you need to look at is a CDN such as Amazon Cloudfront.

Check out these questions for discussions about the usage of CDNs:

Improve this answer
3
  • A colo may actually make more sense, if he can justify the minimum commit (usually 5mb) with 95'th percentile billing. This means, he's never going to pay for the top 5% of peaks, which ends up being cheaper than a third party CDN. Its hard to say, we really need to see exactly how much he's using.
    – Tim Post
    Aug 6, 2010 at 17:03
  • My use will be almost entirely dynamic content, with a heavy CPU/memory footprint per session. After playing with the AWS price estimation tool it seems to be much cheaper to go with colocation.
    – darron
    Aug 6, 2010 at 18:41
  • Ah, I presumed the bandwidth heavy pieces would be media you could put on a CDN, sounds like I presumed wrong. Though if you have dynamic chunks that get processed in a predictable way (a finite set of possible data "chunks") you could still put all that into a CDN. I'll stop trying to guess about your app now. :-)
    – artlung
    Aug 7, 2010 at 1:22
0

Depending on the target state/country (or the world) i would use many cluster ("Cloud") solutions on different locations (location networks should be peered ;-)). On one side you have the full control over your CDN but on the other site you have a lot to do (like monitoring, taking care on soft- and hardware infrastructure and many more).

So "managed" solutions like AWS or something. There are a lot of CDN/Cloud providers which provides a great range of features.

OFFTOPIC: Take a look at Puppet[1] :-)

[1] http://www.puppetlabs.com/

Improve this answer
0

Yes, you should be using Amazon AWS something similar.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.