It's real. Single core performance improves all the time. People overestimate how much power it takes to handle lots of queries per second on a well-tuned system and well-written software in 2024.

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

I see the "sorry, we are receiving too many requests, try again in a few minutes" error several times a day on here. I don't think that HN is reliably able to handle the amount of users it currently has.

I believe that's by design if you send an action request very quickly after a previous one. It's very easy to replicate. Open a post. Then click the upvote button and very quickly click the favorite button too. That will trigger it. I think it's used to rate limit.

>"Sorry, we're not able to serve your requests this quickly" is our little server process saying "help, I only have a single core and I'm out of breath here". If your account were rate limited it would say something like "You're posting too fast, please slow down."

dang, linked in one of the ancestor comments. But I still suspect you are correct.

I just tested it by quickly upvoting your comment and then favoriting it and the error was:

> Sorry, we're not able to serve your requests this quickly. reload

Note that this only seems to happen for actions. Doesn't seem to be the case if I am just loading a page quickly.

I have been using HN daily since I was a teenager. I've seen that message maybe 10 times outside of serious issues in last 15 years. It's strange to me that it happens so frequently for you.

That's difficult to believe to be honest. I get it several times a week.

I get something like that when I try to comment and then upvote too quickly.

There's a manual rate limit that can be assigned to your account if you post frequently on controversial topics. Afaik once it's there it stays until removed by a moderator.

I think that's a little different from what I described, but may be what the grandparent comment described.

I can confirm -- I've only seen this as a form of throttling (i.e. preventing users from sending too frequent HTTP requests).

I've been using hacker news for years and I think I've seen it <10 times too. Maybe our usage patterns differ and I only use HN off peak.

I've been seeing this multiple times a week for the past couple of years. It's gotten worse since 2020. I think that they are preparing to upgrade it, or did upgrade it?

Hmm. I get a different message. Something like "We are having trouble handling your request. Sorry!"

I saw it just a few minutes ago, but I don't remember the exact wording...

Yeah that's the one I meant, I don't remember the exact wording either.

That is a generic rate limiter that is independent of system load. As far as I can tell if you make more than one request per every 5 seconds, you will always be served the rate limit page.

The message for this is something like "we can't serve your requests that fast". The GP is quoting the site overloaded message.

It's a feature

Note that's the application server process being single threaded, but the server machine is 4 core, so nginx cache etc use other cores

A worthwhile distinction!

I looked up the CPU mentioned in the link from your other comment. It looks like HN handles enormous traffic on about 2x the power of the last Celeron chip ever made.

https://www.cpubenchmark.net/compare/2383vs5793/Intel-Xeon-E...

> People overestimate how much power it takes to handle lots of queries per second on a well-tuned system and well-written software in 2024.

I wasn't overestimating anything, but with how easy it is to write concurrently software today, why limit your site to a single core.

Maybe it's a lisp thing. Who knows what mysteries lurk here

It's not a lisp thing. Many lisps are capable of multithreading, including implementations of Common Lisp that have had it far longer than HN has been around, and Clojure, which is extremely good at it.

It even looks like Arc, the lisp HN is written in has threads now, but Arc is built on top of Racket and uses Racket's green threads, so it only takes advantage of one CPU core. Racket does have OS threads, but Arc does not use them.

> well-tuned ... well-written

These are good for actual business needs, but bad for resume-driven development.

Doesn't he mean single socket by single core?

See also: https://news.ycombinator.com/item?id=28478379