On it, fellas. We weren't expecting so many beta signups... didn't think we needed more dynos until launch ;)

Check back in a few minutes, we're already working on it.

How much traffic are you actually getting?

HN doesn't drive all that much traffic to a site, even for sites at the top of the first page. It's virtually nothing compared to what Slashdot could drive to a site in its heyday, or what reddit's front page can drive today.

I don't mean to offend you, but something is seriously wrong with your web app, your database(s) or your other infrastructure if it can't withstand a relatively minor amount of traffic. It's hard to tell for sure given all of the application errors, but it seems like your web app's functionality is pretty basic.

How many requests per second do you think a website needs to be capable of serving to handle the traffic from HN? (Performance newbie here)

Well, it depends on the site in question, of course. But we can make some estimates, if you want.

In the past, I've talked to some colleagues who've had content hit the front page here, and they reported numbers ranging from around 1,000 unique visitors to about 30,000 visitors over a one-day period. So it can vary quite a bit, apparently.

Let's assume that things are more intense than that, and go with 50,000 or so unique visitors in a single hour, distributed rather evenly over that time period, making 2 page views each. Let's also assume that our web server serves up 20 style sheets, JavaScript files, images, and other assets each page view. We'll also assume that this is an interactive web app, so there'll be some database activity, too. No CDN is being used.

So we're talking around 2 million requests over that hour. Since we're assuming they're evenly distributed, for the most part, we'll assume we're dealing with about 550 to 600 requests per second.

That may seem like a lot, but it really isn't. Many of the requests will be for static content (JS scripts, style sheets, images, and so on), so they should be trivial to serve up. Apache or nginx running on a modern, bottom-tier VPS should have no trouble keeping up with this.

Likewise, assuming queries that aren't overly intensive, MySQL or PostgreSQL running on the same server should easily handle a few hundred queries per second. Only a fraction of the requests will actually involve any significant work from the web app itself. It should not be considered unreasonable for the web app to handle a few hundred requests per second.

We won't even consider using a reverse proxy like Varnish, for instance, to reduce some of the load on the web server, web app and database.

Keep in mind that this is a relatively intense scenario, too, at least compared to the activity than can be generated by an appearance on the HN front page, as has been described to me in the past. In reality, we're likely looking at much, much less traffic than in our estimate above, even during the period of peak activity.

Hopefully that helps explain why I think something is very wrong here if a relatively basic web app can't keep up with a relatively moderate amount of traffic.

I doubt that requests are that evenly distributed on a second by second basis so peak response rates might be a few times that for some seconds.

Thanks for the explanation! When you put it that way it doesn't sound so intense.

I've been working at a company where their forums have trouble keeping up with 300 concurrent users in a single forum thread, even when CDN and caching was being deployed and I'm trying to figure out how to improve that.

Still super flaky. Alternating between Application Error and half-loaded pages. :(