How can I detect and survive being “Slashdotted”?

Question

What's a good way to survive abnormally high traffic spikes?

My thought is that at some trigger, my website should temporarily switch into a "low bandwidth" mode: switch to basic HTML pages, minimal graphics, disable widgets that might put unnecessary load on the database, and so-on.

My thoughts are:

• Monitor CPU usage
• Monitor bandwidth
• Monitor requests / minute

Edit: I am familiar with options like caching, switching to static content or a content delivery network, and so on as a means to survive, so perhaps the question should focus more on how one detects when the website is about to become overloaded. (Although answers on other survival methods are of course still more than welcome.) Lets say that the website is running Apache on Linux and PHP. This is probably the most common configuration and should allow the maximum number of people to gain assistance from the answers. Lets also assume that expensive options like buying another server and load balancing are unavailable - for most of us at least, a mention on Slashdot is going to be a once-in-a-lifetime occurrence, and not something we can spend money preparing for.

Answer 1

One word: Knipex

Answer 2

The basics:

1. Don't try to host high-volume sites on Windows unless you are a true Windows guru. It can be done, but it's a time versus cost issue.
2. Use static content (i.e., no database queries) everywhere you can.
3. Learn about cache-control headers and use them properly for images and other static assets.
4. At the very least, use Apache, but if you can, use lighttpd or another high-performance webserver.

The real answers:

1. Really know your SQL, and spend time analyzing slow queries. Most page loads shouldn't require more than a second of straight queries.
2. Determine where your load really is. If it's a media-heavy site, consider hosting content elsewhere (like Akamai, or some other service). If it's a database-heavy site, consider replication.
3. Know what kind of replication will work for you. If you have a read-heavy site, standard MySQL master/slave replication should be fine. If you have a lot of writes going on, you'll need some kind of multi-master setup, like MySQL Cluster (or investigate 'cascading' or 'waterfall' replication).
4. If you can, avoid calling PHP - i.e. have a cached static (HTML) copy of the page (which is what most of the Wordpress caching plugins do). Apache is much faster serving static files than even the simplest hello world PHP script.

Answer 3

Never become popular.

While that will work, it's not real helpful. What you need infrastructure that can scale on very short. Something like Google Gears or Amazon's web services seems ideal for this, since even Slashdot's not going to overwhelm Google or Amazon. If you want your own server make sure your network provider isn't going to cut you off at any preset bandwidth limit. Buy enough hardware so that you're not straining just to carry your normal traffic without any slack to handle sudden spikes.

Answer 4

There are a number of ways this can be done, or at least helped. Search Google for "slashdot-proof" and you'll find a number of them:

• Slashdot-proof your server with FreeCache - Boing Boing
• Simple Thoughts Blog is now Slashdot Proof

etc.

Answer 5

netstat -plant | awk '$4 ~ /:80\>/ {print}' | wc -l

This will show you all of the connections to the Apache server. You can create a cgi script that will calculate the total number of connections to the Apache service and issue a warning once it reaches a certain threshold. What to do at that point is another question.

Hopefully your server is prepared.

Answer 6

For sites that experience high traffic, Akamai is a good solution to make the site fast, extraordinarily scalable, and reliable in spite of your own infrastructure. Akamai is a service (not free) which will cache your site a locations around the world. At my last job, our e-commerce catalog was cached via them and our servers could go down and nobody would know unless they tried adding to their cart. Also, we had our image servers go down once and Akamai's caching saved us again.