Why HN was slow and how Rtm fixed it • Hacker News Board

Re: Why HN was slow and how Rtm fixed it

#161

Post by jwhite » Thu, Jan 20, 2011, 2:57 AM UTC

idlewords wrote: post #151

Not being able to handle 20 requests/sec quickly, in 2011, for a read-mostly website is just shameful.

I think that all depends on the purpose of the site. If I were paying a subscription to access the site I would be within my rights to object. As it is, with HN being a free service, built to be the application spurring the development of Arc, whose reference implementation is intended for exploring language design and not performance, I wouldn't choose the word "shameful" to describe this situation.

Re: Why HN was slow and how Rtm fixed it

#162

Post by mahmud » Thu, Jan 20, 2011, 2:58 AM UTC

dauphin wrote: post #39

Lisp is definitely not a slow language: you can handle the crazy rate of 20 requests/second on a multi-core server!

If you choose to. We pushed north of 800 r/s in production, and just shy of 4k in our LAN, that's using stock hunchentoot with just mere customization.

This guy here broke the 10k barrier:

http://john.freml.in/teepeedee2-c10k

Re: Why HN was slow and how Rtm fixed it

#163

Post by biot » Thu, Jan 20, 2011, 3:22 AM UTC

mbubb wrote: post #100

I find it disturbing to see people asking "Who is Rtm?" "Who is filo?" I understand if you are in tech you might not know figures in history or literature... but these guys? Every time you login to a UNIX/Linux system you use the passwd file and related setup - authored at least in part by Rtm's father. http://www.manpages.info/freebsd/passwd.1.html Rtm has done lots in his own right as the wikipdia pages show. But s…

Who is ESR? ;)

Re: Why HN was slow and how Rtm fixed it

#164

Post by mcantor » Thu, Jan 20, 2011, 4:09 AM UTC

mahmud wrote: post #160

allwein wrote: post #53

When I read this headline, my immediate thought was "Oh, he must have forgotten to shut down the copy of his worm that was running on the HN servers." http://en.wikipedia.org/wiki/Morris_worm

Please, retire that stupid "joke". It's 22 years too old.

First time I had heard it.

Re: Why HN was slow and how Rtm fixed it

#165

Post by mcantor » Thu, Jan 20, 2011, 4:23 AM UTC

taylorbuley wrote: post #36

I feel silly asking, but who or what is 'rtm'?

Someone with a Wikipedia page where the only thing in the "See also" section is "List of convicted computer criminals."

Diagnosis: Badass.

Re: Why HN was slow and how Rtm fixed it

#166

Post by dauphin » Thu, Jan 20, 2011, 4:29 AM UTC

mahmud wrote: post #162

dauphin wrote: post #39

Lisp is definitely not a slow language: you can handle the crazy rate of 20 requests/second on a multi-core server!

If you choose to. We pushed north of 800 r/s in production, and just shy of 4k in our LAN, that's using stock hunchentoot with just mere customization . This guy here broke the 10k barrier: http://john.freml.in/teepeedee2-c10k

You are using multi-cores, it doesn't count (and please stop showing off with your mythical LISP, it doesn't even have hygiene, au contraire Haskell & Javascript).

Re: Why HN was slow and how Rtm fixed it

#167

Post by esbcupper » Thu, Jan 20, 2011, 4:45 AM UTC

mmaunder wrote: post #99

"In 7 seconds, a hundred or more connections accumulate. So the server ends up with hundreds of threads, most of them probably waiting for input (waiting for the HTTP request). MzScheme can be inefficient when there are 100s of threads waiting for input -- when it wants to find a thread to run, it asks the O/S kernel about each socket in turn to see if any input is ready, and that's a lot of asking per thread switch…

Filo's BSD hack to buffer the entire HTTP request and then pass it on has the same effect as using nginx here.

It doesn't help with keepalive though, but that's probably not needed.

Re: Why HN was slow and how Rtm fixed it

#168

Post by dauphin » Thu, Jan 20, 2011, 4:50 AM UTC

mahmud wrote: post #160

allwein wrote: post #53

When I read this headline, my immediate thought was "Oh, he must have forgotten to shut down the copy of his worm that was running on the HN servers." http://en.wikipedia.org/wiki/Morris_worm

Please, retire that stupid "joke". It's 22 years too old.

Rtm was not born 22 years ago!

Re: Why HN was slow and how Rtm fixed it

#169

Post by piotrSikora » Thu, Jan 20, 2011, 5:09 AM UTC

nuclear_eclipse wrote: post #81

rarrrrrr wrote: post #72

Since no one has mentioned it yet - Varnish-cache.org, written by a FreeBSD kernel hacker, has a very nice feature, in that it will put all overlapping concurrent requests for the same cacheable resource "on hold", only fetch that resource once from the backend, then serve the same copy to all. Nearly all the expensive content on HN would be cacheable by varnish. Then you can get it down to pretty close to "1 backend…

Reverse proxies won't work for HN, because requests for the same resource from multiple users can't use the same results. Not only are certain bits of info customized for the user (like your name/link at the top), but even things like the comments and links are custom per user. Things like users' showdead value, as well as whether the user is deaded, can drastically change the output of each page. Eg, comments by a d…

Of course it will work. The whole point of reverse-proxy is to buffer slow requests and send them fast over LAN to your back-end servers that cannot handle high concurrency efficiently.

The FreeBSD's accept_filter() used by Rtm does more or less that (you can think of it as of reverse-proxy in the kernel), but it only works for plain HTTP and HEAD/GET methods.

Re: Why HN was slow and how Rtm fixed it

#170

Post by ezalor » Thu, Jan 20, 2011, 5:14 AM UTC

ezalor wrote: post #150

pg wrote: post #129

Earlier quoted context omitted.

I just wanted to have them in the language. The fact that I don't currently use them in HN doesn't mean they're useless.

I always thought the purpose of Arc was to be cruft-free, "don't include it unless it is actually needed".

Yeah, it hurts right? You failed, sorry, but it's not my fault (think 50 cents).