I feel silly asking, but who or what is 'rtm'?
Why HN was slow and how Rtm fixed it
41–50 of 202 posts
Re: Why HN was slow and how Rtm fixed it
#42Sounds like there is a scalability issue within MzScheme in that it iterates over the number of threads, asking each thread about the sockets it has. As one can tell, once # of threads and # of sockets grow - finding which thread to run in user space becomes awfully expensive. As any clever admin will do, a least invasive fix involving limiting the number of connections and threads was done - with what sounds like im…
MzScheme is an implementation of Scheme (dialect of Lisp); it implements its own threading. This is not uncommon for languages which support (or used to support) many OSes, with many different versions of threading: it's easier to write it yourself, once, than maintain N+1 OS-specific versions.
Of course, these days, N+1 is probably 2, since everything except Windows supports pthreads.
Re: Why HN was slow and how Rtm fixed it
#43I feel silly asking, but who or what is 'rtm'?
Book worm, nerd. Think Comic Book Guy, but healthier and smarter. Totally a bad-ass.
Re: Why HN was slow and how Rtm fixed it
#44I feel silly asking, but who or what is 'rtm'?
"Robert Morris, the other founder of Viaweb, whose username
is Rtm"
Re: Why HN was slow and how Rtm fixed it
#45I feel silly asking, but who or what is 'rtm'?
[deleted]
Re: Why HN was slow and how Rtm fixed it
#46Sounds like there is a scalability issue within MzScheme in that it iterates over the number of threads, asking each thread about the sockets it has. As one can tell, once # of threads and # of sockets grow - finding which thread to run in user space becomes awfully expensive. As any clever admin will do, a least invasive fix involving limiting the number of connections and threads was done - with what sounds like im…
not to mention that one thread per connection is, well, extremely outdated.
I don't know much about MzScheme, but it's quite possible that "thread" means "stack", not "OS thread". One context stack per TCP connection is quite sustainable; with Haskell's threads and Perl's coros, I run out of fds long before I'm using any significant amount of memory. (This is somewhere around 30,000 open connections on my un-tweaked Linux desktop. I know I can do a lot more if I tried.)
The issue, in the case of HN, is with O(n) IO watchers. Most sockets are idle most of the time, so you really want an algorithm that is O(n) over active sockets, not O(n) over active and inactive sockets. You typically have so few active fds at any time that the n is really tiny, making massively scalable network servers trivial to write. But you also have a lot of connections at any one time, so if you are O(n) over active and inactive fds, then you are going to have performance issues. Basically, you don't want to pay for connections that aren't doing anything.
Fortunately, we have the technology; epoll on Linux, kqueue on BSDs, /dev/poll on Solaris. You just need to use an event loop, so it does all the hard stuff for you (and so you don't have to worry about the OS differences). Hacking a proper event loop into MzScheme may be hard, but it's absolutely necessary for writing scalable network servers. Handling 10k+ open connections is trivial with today's technology. And, all the cool kids are doing it (node.js, GHC, etc.).
Re: Why HN was slow and how Rtm fixed it
#47I feel silly asking, but who or what is 'rtm'?
Re: Why HN was slow and how Rtm fixed it
#48I feel silly asking, but who or what is 'rtm'?
[deleted]
Re: Why HN was slow and how Rtm fixed it
#49YC ranks 2400 on Alexa, and I'm sure most of the traffic is HN. I bet you'd be hard-pressed to find a top 10k site written in Scheme. Does anyone know of one? http://www.alexa.com/siteinfo/ycombinator.com
Not yet. Working on it.
Re: Why HN was slow and how Rtm fixed it
#50Sounds like a switch to async I/O would be helpful.