5

I have a web application that I expect to go viral pretty quickly.

How can I control traffic to it so that it doesn't crash under too much load?

This application doesn't require user login. It will be properly load tested, but I am not really sure what kind of traffic to expect until I make it live.

Mag20
  • 3,281
  • 2
  • 23
  • 21
  • 3
    Why do you expect it to go viral? Far more people think that their baby will, than actually experience that... – btilly Nov 02 '13 at 18:32
  • 3
    It may or may not. But if it does and servers crash - people may not come back. – Mag20 Nov 02 '13 at 19:26
  • Why not use a cloud service which automatically scales with its load? – Andy Nov 03 '13 at 10:23
  • It is expensive. I am using Azure shared websites, which cost $10 per month per instance. They don't allow scaling automatically. The next tier, "Standard" website - can scale auto, but costs $80 per instance. That's a big difference in price. – Mag20 Nov 03 '13 at 21:55
  • 1
    My experience with low cost plans is they don't support more than a few concurrent users. Either your site won't go anywhere and you won't be out much money, or you will jump to that higher tier and start paying incrementally more based on volume. I hope you have a revenue plan that scales along with your numbers growth. – Bill Leeper Nov 04 '13 at 15:41

4 Answers4

5

It is harder to control without a login.

Another option is to protect the site with an "access key" that you can then give out to your beta users. I personally don't like these and they will inhibit initial expansion of your site since all users will need this key and the site won't be indexed by Google etc.

Your best be is to do some load testing. Address the bottlenecks in your code and have a scale out plan if you think it will expand quickly. You need to have this plan ready so you can just click a button and add another load balanced server etc.

Bill Leeper
  • 4,113
  • 15
  • 20
1

What is your bottleneck?

Assuming that bandwith is your problem, e.g. by serving high-res images, then using a CDN will be beneficial.

If your site is computationally expensive, then load-balancing between multiple servers sounds like the way to go. Hosting your webapp in a cloud will make this scaling easier, and you can always scale down or move to a conservative solution when you can accurately estimate the number of users. Scaling across multiple servers can get difficult if the users interact with each other using your site. In that case, peer-to-peer communication between users, or a message queue between your servers sounds like a good idea.

You might want to tweak your technology stack towards better performance. Static content can be cached. If you are running an interpreted language on the server, an alternative implementation may have a better performance profile (possibly trading start-up time or memory for overall faster execution). There is no excuse for using CGI scripts in this day and age for a modern webapp.

I don't know how you will roll out your site. If you are targeting an international audience, one possibility would be to release the site at a certain local time for each user. A variation of this would be to display the site as closed to a certain percentage of IPs when load is high. However, requiring an email address to log in would actually be preferable. If load is high, tell the user he'll get the activation email in about ten minutes (but then, give him priority). You could also give out URLs with an access token to specific individuals before officially opening the site. You can then try to estimate public interest from various metrics like percentage of people that used their tokens, number of tweets, ….

A controlled launch can be achieved by giving each pre-opening user a number of further tokens, which he can give away. This allows you to adjust the rate of expansion, until you open to the general public. Be careful with such tactics: while artificial scarcity can increase interest, this also makes it harder to your product to “go viral”.

If there are few fixed slots for users available, you could display their position in a waiting queue and perhaps give a clue on the remaining waiting time. How you can reduce the perceived waiting time is an interesting UX question.

In the end, this is not only an interesting technical question, but also a matter of marketing.

amon
  • 132,749
  • 27
  • 279
  • 375
1

As a newbie to this site and the risk of not knowing proper etiquette, why don't you design the application with scale-out in mind, immediately. Start with a scale-out NoSQL or similar database on the back end, caching layer below the site, distributed services that scale automatically (SOA, if you will) or as someone says at the press of button. The window of opportunity is narrow on things, why not plan for fast expansion and catch the wave versus trying to control users. There are software frameworks that you can build with right now, depending on what technologies you need, that have scale out in mind.

0

Use a Load Balancer to direct traffic to two sites, one being the live site, the other being a welcome page with a friendly message asking the visitor to try again later...

ChuckCottrill
  • 525
  • 3
  • 8