11–20 of 44 posts
> With amazon's EC2 service, I'll be able to deploy as many temporary mirrors as I need in just a few minutes Can you go into detail on how does that work? I thought you had to have your site originally hosted on EC2 to do that ...
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.
That's it. That will allow your little out-of-the-box slice handle all the traffic that we can throw your way.
Scaling is an issue that you're meant to have with your product. Because your product actually needs to talk to databases and do things, it may have trouble doing those things when lots of people hit it at once. A website hosting a blog, on the other hand, needs to serve files. And that's been a solved problem for fifteen years.
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 enough threads to use all the available resources, but it will only make a difference if you aren't idling all those threads with a high KeepAliveTimeout. Apparently, that's the Apache default setting.
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…
There have been three posts on my blog this year which would, with absolute engineering certainty, have effectively DOSed Apache if I had kept the Ubuntu default settings. All involve numbers which are really small for computers, like 300k (hits in a day)
It took me years of blogging to realize why this happened and address it, despite my blog running on a beefy machine and me theoretically having experience with much harder problems than serving 20k of plain text repeatedly.
Its drastically oversimplified if you need to scale an application. "Step 2: Make content static". For an actual application, there is far more to say than 4 sentences.
In my opinion:
* There are few cases where Apache is better than nginx. I don't run PHP, so that may be still there. * Varnish is awesome, use it, love it. * Purely static blogs, like jekyll, are great.
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…
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.
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…
The problem became unsolved in the interim, largely because it was virtually impossible for the 2001 Internet to overwhelm the limits of Apache's default settings, whereas it is fairly easy in 2011 to do that with social media. There have been three posts on my blog this year which would, with absolute engineering certainty, have effectively DOSed Apache if I had kept the Ubuntu default settings. All involve numbers…
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 you're stuck with traffic to your blog, you should look at an existing caching solution and maybe scale your VPS a little. It's not likely to be a permanent thing.
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…
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 don't know whether to be happy or sad about that.)
Basically, there are a couple of Apache MPMs available. You may have the prefork MPM installed. You can check by running "apache2 -l". If you see prefork in the output, take a look at your config file (quite possibly /etc/apache2/apache2.conf) and check for the setting" KeepAlive On". If KeepAlive is on, your blog is broken and you just haven't found the failure condition yet.
On my server (Ubuntu, has gone from Dapper to Lucid over the years), the package default Apache2 settings for the prefork MPM are: 15 second keepalive, 150 MaxClients. If your server has enough RAM to support 150 processes for Apache (and, if you're on a VPS, you probably don't), that will let you process a hard theoretical maximum of 600 clients per minute. There are many, many things you can do to exceed that maximum bound: getting on the front page of Reddit or getting retweeted by Jimmy Wales at the right hour of the day both qualify.
Calculation: any client requesting any file, regardless of whether it is dynamic, static, cached, generated by a PHP monstrosity, whatever, occupies one process for a hard minimum of 15 seconds. 4 clients saturate one process for 1 minute.
With special attention to fellow VPS owners: after having died hard several times when apache2 decided to use up all available RAM and then swap the machine to death, I eventually tweaked the MaxClients setting down to 24. This means that, even with KeepAlive at 2 seconds, my max throughput was 720 clients per minute. Again, that number is achievable under very plausible circumstances for a personal blog in 2010/2011.
There are a variety of countermeasures one can take against this. One is not using the prefork MPM, but you have to be a configuration Jedi to figure out how to actually do this and still run PHP on your server. "apt-get install apache2 libapache-mod-php5", which is what substantially all guides will tell you to do, will force you to use the preform MPM. If you had been using the worker MPM instead, you would have a much, much harder time crashing your server serving static content.
Another alternative: switch to Nginx. This problem goes away instantly. (If I didn't have 15 config files I would have to migrate, I would have done this years ago.)
The easiest alternative: turn off KeepAlive. This will give you a very modest throughput hit, but I'll trade "Blog stays up if mentioned in the NYT" for that hit any day of the week.
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…
The problem became unsolved in the interim, largely because it was virtually impossible for the 2001 Internet to overwhelm the limits of Apache's default settings, whereas it is fairly easy in 2011 to do that with social media. There have been three posts on my blog this year which would, with absolute engineering certainty, have effectively DOSed Apache if I had kept the Ubuntu default settings. All involve numbers…
I'm afraid I'm going to have to stand by my assertion that static file hosting is a solved problem in 2011. I think the real issue we're seeing with all these "Slashdotted blogs" is that the database-based-blog is the 20 minute intro lesson for every new server-side tech. The result is that everybody thinks about blog hosting as a problem involving taking content from the database and displaying it to the user. This leads to things like caching and other performance hacks that could be done away with if you simply thought of the problem in terms of hosting files.