Home / server / Questions / 111
Accepted
mathieu
Asked: 2009-05-01 00:33:45 +0800 CST

First days online : how not to kill your site

  • 772

Suppose you have this fancy new site, with lots of data (like big images), and you're about to put it online. If you do "too much" publicity, during the first days, the site will be overwhelmed with requests.

How can I mitigate this risk ?

I've thought of

  • going live gradually, like SO and SF : "private" beta, public beta, public
  • allow X connections sessions concurrently, so the connected user still have good experience of the site, and the others have a nice apology message

I can't :

  • buy more servers, as after the first days, the site will have a lot less traffic :)
performance website optimization traffic

6 Answers

  1. Best Answer
    1. Cache as much as you can. Any pages that are dynamically created should be cached so that users will get a static version. In page components that query the db should also be cached.
    2. Try using an external service like Amazon S3 to serve images and multimedia (or have it ready to use if the site suddenly gets hit with a ton of traffic).

    Going live gradually can worked for SOF and SF because they already had built-in publicity and demand, due to the popularity of Jeff and Joel's blogs. If you do not have a near-guaranteed userbase like they did, then going live gradually could be fatal.

    I would avoid limiting by concurrent sessions, as it is hard to define the end of a session caused by inactivity. If a user leaves for 15 minutes and tries to reload their page, only to get an error message - you just lost a user.

    • 11

  2. How much planning went into your data model ? Have you designed a schema that will allow you to ramp up your query volume without expensive sorts, binary columns, or complex joins ? Have you tuned your database backend (assuming you have one) ?

    How are you serving your 'big images' ? Can you split that out into a separate web server process, even a separate domain ?

    Have you load tested your system ? Tools like ApacheBench and Siege are invaluable.

    Is all your configuration in svn ? Is your deployment automated ? You'll be glad of that when you have to roll our application out to the 2nd server.

    • 5

  3. An invitation system can sometimes be a good way to control user uptake of a site. Pass out a certain number of invites at the beginning, so that the site doesn't become overwhelmed. Then give each user a few invites to pass around to others, slowly building up the number of users on the site. That way you won't get too many people hitting the site at the beginning, and you don't get a massive peak of traffic.

    The downside of course is that you may be turning away a lot of users at the beginning who don't have invites, and who may not return later on. Unless you have a really good site that people are very excited to use, then this could be a bad move. It depends on the site really. Plus you'd actually have to have some extra development time to add an invitation system.

    • 1

  4. I'd make sure that you had a robust monitoring infrastructure in place prior to launch. You need to have data to base your decisions on- this means measuring CPU load across the servers, checking that your load is spread evenly across boxes, and that if something melts down, you know which one it was.

    Knowing where the problem is will dramatically reduce the time it takes to respond. I've seen too many sites launch without monitoring of any kind, with the intention that it will be set up later... after the fire is out. This is profoundly wrong.

    • 1

  5. You might want to look into 3rd party hosting of static content such as Amazon S3. It might be worthy depending on your application to also cloud some (as much as I hate the buzzword) using Amazon EC2.

    • 1

  6. Some hosting providers allow you to test private servers with max capacity for a while and then settle on a reasonable capacity after the trial period.

    DreamHost is one example:
    http://www.dreamhost.com/hosting-vps.html

    • 0