Hacker News Reader

Comment by Jabbles | Hacker News Reader

200 hits per minute? Is that all it takes?

(I guess the answer is "No, only if you've misconfigured", but still...)

A misconfigured site that serves all its own assets will perform terribly because 200 hits per minute x 20 assets = 4,000 hits per minute. Wordpress has tons of assets too.

Never used WP, but aren't those static assets? The bottleneck would be bandwidth then, should not be a huge load on the server. If it's compiling stuff or fetching them from DB though, then that could cause some problems.

It has to do with the number of requests plus the number of allowed processes plus the requests each process was allowed to serve. At a limit of 300 requests per process, the processes fell over at about 3 seconds time. With only 20 processes, dying every three seconds, the server was overwhelmed. So it's really a combination of issues.

Looking at the records for MySQL data, there wasn't that much of an issue there with MySQL connections. This is probably due to the fact that the page cache was working correctly.

The approach I've been taking with my recent projects is to serve all static assets from Amazon S3/CloudFront. That way 200 hits per minute is only 200 requests. 19 of those 20 assets in your example would get served from the CDN. I don't have a lot of experience building robust apps (I'm a self-taught hobbiest developer) but intuitively this configuration makes sense and it has been incredibly easy to implement. I did some stress testing for the first time on one of my apps using jmeter and was able to achieve much higher performance that 200 hits per minute on my free micro instance.

I was expecting a lot more that that given the number of servers going down as soon as they hit the front page.

I think that most people leave it configured for default and never bother to do any kind of caching. My server was down less than five minutes because I knew what to look for.

Reply on news.ycombinator.com