Live data from Hacker News

Why HN was slow and how Rtm fixed it

ycombinator.com

1–10 of 202 posts

Re: Why HN was slow and how Rtm fixed it

#3
> when [MzScheme] 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

They've never heard of select()?

But really, is there some reason that it's hard to collect up all the fds at once or something?

Re: Why HN was slow and how Rtm fixed it

#5
The traffic graphs linked in this post [0] are an interesting addition to the "How often do you visit HN?" poll [1] that was done a week ago. From the graphs, it looks like there are about 10x as many page views as unique IPs.

[0] http://ycombinator.com/images/hntraffic-17jan11.png [1] http://news.ycombinator.com/item?id=2090191

Re: Why HN was slow and how Rtm fixed it

#6
I worked at a startup once that made a network card that did this type of buffering (wait for whole HTTP requests, then forward as a lump to the host, across a local fast bus).

Pretty whizzy, definitely helped server scaling.

We started shipping in 2001; the dot-com bust more or less canceled any interest in the product, and canceled the company, too . . .

Re: Why HN was slow and how Rtm fixed it

#9
"It turns out there is a hack in FreeBSD, invented by Filo, that causes the O/S not to give a new connection to the server until an entire HTTP request has arrived."

I wouldn't call it a hack, but a feature ;-)

    # Buffer a HTTP request in the kernel 
    # until it's completely read.
    apache22_http_accept_enable="yes"
Is HackerNews web scale?
Post reply on HN