Hacker News Reader

Comment by wheels | Hacker News Reader

It's a site with in the ballpark of 60k uniques per month. What they use is pretty irrelevant. Really all this reduces to is, "it's dumb to optimize for problems you don't have."

Assuming 100 requests per user per month, 60k uniques is 2 requests per second. They could run the whole site on one Linode unless they've got a particularly bad architecture.

View on HN

> 2 requests per second

Your point is valid, but it doesn't work like that.

Do you care to elaborate?

Traffic is bursty, not smooth.

Taking daily pageviews and dividing it by 24 * 60 * 60 assumes your traffic curve isn't a curve at all - it's flat. For your average US-based consumer web app it's highly unlikely to have just as many people using your app at 3am as you do 3pm.

When scaling a web app, you need to prepare for peak usage, not average usage.

Here are a few first-hand examples. Friends for Sale, a social game, had ~10M daily pageviews (100 req/sec avg) but had peak load of > 200 req/sec. Ideeli, a "flash sale" designer shopping site, typically had peak load 5x-20x higher than median load.

Regardless of what Quora's traffic curve looks like, wheels' point still stand - it doesn't matter what backend you're using for 60k users on a web app.

--------------

http://highscalability.com/friends-sale-architecture-300-mil...

So worst case they will be doing 4 req/s instead of 2.

I know what you're trying to say, but at Quora's numbers, as OP said, it truly is irrelevant.

No, 5-20x * 2req/s av = 10 to 40 req/s.

Peak on a decent traffic site will be roughly 2x-3x the average. 5x-20x would be a blog that gets 10 visitors a day and after being posted on news.yc gets 100 visitors.

There's an entire branch of mathematics that covers this. It's called "queuing theory". It's pretty strait forward to find the probability of N requests per second for an M/M/1 system. Then you decide, "I want to be able to handle the 99.9% case" (or whatever) and you know what your peak capacity has to be.

Without estimating the traffic of the author's site, I still find his argument valid.

I've employed many of the tactics he describes and have achieved >15 M/s of dynamic content through MySQL. Not Facebook, but it was fast and scalable for the market my app was geared towards.

Reply on news.ycombinator.com