Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why HN was slow and how Rtm fixed it

ycombinator.com

Post reply on HN
Print view View original

81–90 of 202 posts

Re: Why HN was slow and how Rtm fixed it

#81

Post by nuclear_eclipse »

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 deaded user won't show as dead to that user, but they will for everyone else...

Re: Why HN was slow and how Rtm fixed it

#82

Post by [deleted] »

jwr wrote: post #54

Which is why it's good to have a mature VM underneath your language. Paul's choice of basing an implementation of Arc on MzScheme was a very good one (I remember people criticizing him for not building a standalone implementation with a new VM). I write time-critical applications in Clojure and JVM's -XX:+UseConcMarkSweepGC flag is a lifesaver. We no longer get those multi-second pauses when full GC occurs.

[deleted]

Re: Why HN was slow and how Rtm fixed it

#83

Post by djcapelis »

kirubakaran wrote: post #64
djcapelis wrote: post #56

Earlier quoted context omitted.

Did you just tell people running a company that reinvented funding with their custom written news site written in their own programming language with a custom web server that they shouldn't re-invent the wheel? They think they can build a better wheel. They seem to like doing it and have a habit of it. There's nothing wrong with that.

Unless they built their server with nand gates, I don't see running nginx reverse proxy to be incoherent with their philosophy.

Right, they only re-invent wheels when they feel they can make a better one. I don't think they feel they can go through the effort of fabricating a better chip. Though I wouldn't put it past rtm to try.

The philosophy "Don't reinvent the wheel" however, is definitely inconsistent with their philosophy. They will reinvent the wheel whenever they feel they can make a better one. Just because they haven't reinvented every wheel does not mean "don't reinvent the wheel" applies to this group.

They chose to create the best solution they think they can. They don't seem to care whether or not that involves reinventing wheels. The original argument that they should seems pretty silly.

Re: Why HN was slow and how Rtm fixed it

#84

Post by dminor »

j_baker wrote: post #78
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…

Can't you only use varnish for mostly non-dynamic content? Like for example, wouldn't the fact that it displays my username and karma score at the top of the page make it so that you couldn't use varnish (or at least make it more difficult)?

Yes, you'd have to somehow separate the dynamic content from the static content so they could be fetched in different requests and then combined (probably via ajax). If it's just your username and karma then it's simple enough, but if the comments are displayed differently for different people then it could be bear.

Re: Why HN was slow and how Rtm fixed it

#85

Post by seiji »

j_baker wrote: post #78
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…

Can't you only use varnish for mostly non-dynamic content? Like for example, wouldn't the fact that it displays my username and karma score at the top of the page make it so that you couldn't use varnish (or at least make it more difficult)?

Check out http://www.varnish-cache.org/trac/wiki/ESIfeatures

There could be a private internal URL to just return username and karma to populate the user info header.

Re: Why HN was slow and how Rtm fixed it

#86

Post by blinkingled »

metageek wrote: post #42
blinkingled wrote: post #13

Sounds 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.

If it's just a porting issue, there is Pthreads-win32 which worked well enough the last time I used it few years ago.

Re: Why HN was slow and how Rtm fixed it

#87

Post by rfugger »

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…

To make this work you could do all the per-user stuff with javascript and ajax calls in the browser. It would be quite a bit of revamping though.

Re: Why HN was slow and how Rtm fixed it

#88

Post by jhrobert »

pg wrote: post #77
axod wrote: post #66

1 thread per connection??? Not doing continual GC in a separate thread and instead taking 7 seconds and blocking everything? What is this the 1990s?

Feel free to fork MzScheme and replace the garbage collector with a new one that runs continuously.

There is no such thing as a free lunch

Re: Why HN was slow and how Rtm fixed it

#89

Post by metageek »

blinkingled wrote: post #86
metageek wrote: post #42

Earlier quoted context omitted.

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.

If it's just a porting issue, there is Pthreads-win32 which worked well enough the last time I used it few years ago.

I don't know the details. I suspect the answer is that the threading support was written when pthread support was less common, and the MzScheme developers haven't been sufficiently interested in rewriting it.

Re: Why HN was slow and how Rtm fixed it

#90

Post by Aaronontheweb »

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…

So, you can't do donut caching in Varnish?
Post reply on HN