Live data from Hacker News

Surviving a traffic surge: Three techniques to scale your site fast

matt.might.net

31–40 of 44 posts

Re: Surviving a traffic surge: Three techniques to scale your site fast

#31
post #16

No. Stop it. Never ever scale your blog. It sounds like the author was making the same mistake that pretty much everybody makes: Treating your blog as though it were dynamic content. But it's not. It's static HTML, and you should never have to make any modifications to anything to make it scale. Step one: Have your blog export all entries to plain HTML. Step two (optional): move your imagery out to S3/Cloudfront. Tha…

If the blog supports comments, it needs to talk to databases. Step one: Have your blog export all entries to plain HTML. He did that. A website hosting a blog, on the other hand, needs to serve files. And that's been a solved problem for fifteen years. "Too few Apache threads" is a known problem, which he recognized as soon as he saw the load numbers.

> If the blog supports comments, it needs to talk to databases.

Sure, but it doesn't have to fall over. Outsourcing to Disqus is the easiest solution, but you can build your own AJAXy solution. Or just write out a new static file for each comment (if you're really overloaded, comments may take a while to be processed, but you can just serve the old page in the interim.)

Re: Surviving a traffic surge: Three techniques to scale your site fast

#32
post #19
post #13

These are decent tips, but the real fix for me when I got a (minor) traffic surge was changing KeepAliveTimeout from 15 (sec) to 2 (sec). Basically, due to the high default keep alive time for requests, most Apache threads were waiting for the timeout. So the number of threads you have (e.g. setting StartServers, MaxSpareServers/MaxSpareThreads) is way less important than the keepalive timeout: you can/should start e…

Ding ding ding, we have a winner. KeepAlive can even kill your blog at 2 (achievement unlocked 4 times over last year). Edit to elaborate: Sorry, was eating dinner and Kindle is not exactly made for typing on technical documentation. This comment is a abbreviated version of http://www.kalzumeus.com/2010/06/19/running-apache-on-a-memo... -- read that if you want a longer spiel. (It is my most cited blog post on HN. I…

Do you run your site with keepAlive set low all the time or only when needed?

Re: Surviving a traffic surge: Three techniques to scale your site fast

#33
post #19

Earlier quoted context omitted.

Ding ding ding, we have a winner. KeepAlive can even kill your blog at 2 (achievement unlocked 4 times over last year). Edit to elaborate: Sorry, was eating dinner and Kindle is not exactly made for typing on technical documentation. This comment is a abbreviated version of http://www.kalzumeus.com/2010/06/19/running-apache-on-a-memo... -- read that if you want a longer spiel. (It is my most cited blog post on HN. I…

Do you run your site with keepAlive set low all the time or only when needed?

KeepAlive is off 100% of the time because "Wake up at 3 AM in morning, in response to my cell phone playing Ride of the Valkyries because a server is offline, to tweak the config file locking out thousands of people who want to see my writing" is sensible precisely 0% of the time.

Re: Surviving a traffic surge: Three techniques to scale your site fast

#34
My number 1 tip: ditch Apache.

One of my web apps has the occasional spike in traffic that previously caused Apache to consume vast amounts of memory on my VPS, eventually crashing it due to lack of memory.

After reading many guides, experimenting, and generally getting quite frustrated (and working out what VPSs I could afford to upgrade to), I tried setting up Nginx on a separate port. It took maybe 1 hours for me to have my former LAMP stack set up and working, so I put it live, and haven't looked back since.

If you're on a VPS, use Nginx. The config file is wildly different to that of Apache, and you'll no doubt spend a few minutes cursing trying to figure out how to port over your rewrite rules, but after that it's plain sailing.

Re: Surviving a traffic surge: Three techniques to scale your site fast

#35

My number 1 tip: ditch Apache. One of my web apps has the occasional spike in traffic that previously caused Apache to consume vast amounts of memory on my VPS, eventually crashing it due to lack of memory. After reading many guides, experimenting, and generally getting quite frustrated (and working out what VPSs I could afford to upgrade to), I tried setting up Nginx on a separate port. It took maybe 1 hours for me…

This. As an added bonus, I've also found that I prefer Nginx's configuration files.

Worst case, you can serve static files with Nginx and route dynamic requests to your Apache instance (I still do this with a few old PHP apps I have).

Re: Surviving a traffic surge: Three techniques to scale your site fast

#36
post #8

Using a reversed proxy (e.g. nginx's built in, or maybe varnish) is a much easier and dynamic solution then to render things to static files.

Agreed. Heroku makes it dead simple to use their Varnish proxy. Just set one http header and they'll cache the page for you. After that, your app doesn't do anything until the cache expires. This obviously won't work for highly dynamic pages, but for semi-static front pages/blog entries it can be a lifesaver.

Re: Surviving a traffic surge: Three techniques to scale your site fast

#37
One [probably naive] thing that I've done in the past has been to use mod_rewrite to redirect people to a static version of a page.

Something like this would work in .htaccess

RewriteRule ^t/item/4372/$ /static/4372.html

It's saying "Hey, apache, if you see somebody asking you for website.tld/t/item/4372/, send them to website.tld/static/4372.html instead"

A blog post I wrote got about 100k hits in a day a few weeks ago, and using mod_rewrite in this fashion, I was able to keep the site running for the entire day.

Re: Surviving a traffic surge: Three techniques to scale your site fast

#40

600 MaxClients on a Linode box with 512MB RAM? At this point, it became quite clear that this article isn't going to be hugely useful.

what would you recommend instead?

Apache's memory usage should not exceed the available RAM on the machine. If you do that, it starts having to use swap, which drastically slows things down - if you're already getting lots of hits, it'll start a death spiral.

Apache's memory usage varies based on what modules are enabled and the code they're serving and a number of other factors.

The rule of thumb is to take the average free RAM when Apache isn't running, divide it by the average RAM usage of a single Apache process on your system, and set MaxClients to a couple under that value.

For example, on a 512MB Linode box, if you've got 450MB free when Apache isn't running, and Apache takes up 12MB per process, you'd allow about 35 at the most.

Post reply on HN