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

Node.js memory benchmark confirms V8's GC may not be ready for the server

hns.github.com

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Node.js memory benchmark confirms V8's GC may not be ready for the server

#21

Post by sh1mmer »

hannesw wrote: post #11
sh1mmer wrote: post #7

I think the editorializing of the headline is unnecessarily negative (read biased). There is obviously an issue Ryan is working on addressing but Node is clearly already providing performance which is suitable for many server workloads.

I'm the author of both the original article and this HN posting - and yes, I am biased, since I'm the main developer of RingoJS (the other platform in that benchmark). I've made that quite clear and provided additional background in the original benchmark to which this is just a short update: http://hns.github.com/2010/09/21/benchmark.html I think my benchmark and the conclusions I draw from it (after a lot of thinki…

I think your conclusions in the article are fair. I think the title on HN is misleading because it's a quantitive issue.

V8 GC is a well known concern in the Node community, but it's still performing well enough that Node is considerably faster than traditional servers (like Apache). The fact that Ringo is also faster doesn't make V8 "not ready" it just means it could be improved.

If I wanted to be contentious I could suggest that "Hacker News comments confirms that RingoJS may not be ready for developers" because the author likes taking pot shots at other frameworks. But that would be petty, wouldn't it?

Re: Node.js memory benchmark confirms V8's GC may not be ready for the server

#22

Post by js4all »

First, the response time variation is an important observation, thanks for that. To make sure, that it is caused by V8's CG, we need a GC log from the benchmark.

Second to make this a fair comparison, you need to use a similar sized heap. It could be, that the JVM heap was large enough to run the whole test without a major CG. We need a GC log also for this part of the test.

Sun was aware of the different CG strategies needed for server and client use and let us choose between them. V8 however seems the be optimized for the client side.

Re: Node.js memory benchmark confirms V8's GC may not be ready for the server

#23

Post by IsaacSchlueter »

I'm not yet convinced this is due to GC. Sent a pull request[1] to Hannes to use the faster Buffer technique, to at least rule out the interference of v8's crazy slow string juggling under load.

1: http://github.com/hns/ringo-node-benchmark/pull/1

Re: Node.js memory benchmark confirms V8's GC may not be ready for the server

#24

Post by z92 »

sh1mmer wrote: post #21
hannesw wrote: post #11

Earlier quoted context omitted.

I'm the author of both the original article and this HN posting - and yes, I am biased, since I'm the main developer of RingoJS (the other platform in that benchmark). I've made that quite clear and provided additional background in the original benchmark to which this is just a short update: http://hns.github.com/2010/09/21/benchmark.html I think my benchmark and the conclusions I draw from it (after a lot of thinki…

I think your conclusions in the article are fair. I think the title on HN is misleading because it's a quantitive issue. V8 GC is a well known concern in the Node community, but it's still performing well enough that Node is considerably faster than traditional servers (like Apache). The fact that Ringo is also faster doesn't make V8 "not ready" it just means it could be improved. If I wanted to be contentious I coul…

> The fact that Ringo is also faster doesn't make V8 "not ready" it just means it could be improved

Well said. Most of us fail to realize this simple point until someone points out.

Re: Node.js memory benchmark confirms V8's GC may not be ready for the server

#25

Post by hannesw »

sh1mmer wrote: post #21
hannesw wrote: post #11

Earlier quoted context omitted.

I'm the author of both the original article and this HN posting - and yes, I am biased, since I'm the main developer of RingoJS (the other platform in that benchmark). I've made that quite clear and provided additional background in the original benchmark to which this is just a short update: http://hns.github.com/2010/09/21/benchmark.html I think my benchmark and the conclusions I draw from it (after a lot of thinki…

I think your conclusions in the article are fair. I think the title on HN is misleading because it's a quantitive issue. V8 GC is a well known concern in the Node community, but it's still performing well enough that Node is considerably faster than traditional servers (like Apache). The fact that Ringo is also faster doesn't make V8 "not ready" it just means it could be improved. If I wanted to be contentious I coul…

You are right about the title. That "not ready for the server" is a foolish phrase. I'd change it to "not tuned for the server" if I could, but it looks like it's impossible to change that now.

Re: Node.js memory benchmark confirms V8's GC may not be ready for the server

#26

Post by mraleph »

felixge wrote: post #16

To the author of this article: Could you run your node test with "node --trace-gc " turned on? That will output when, and for how long, node's GC is doing it's thing. Anyway, this could be a legit complaint at this point.

--trace-gc will show an endless sequence of mark-sweep/compacts.

I explained why that happens in my comment to the original post.

Re: Node.js memory benchmark confirms V8's GC may not be ready for the server

#27

Post by felixge »

mraleph wrote: post #26
felixge wrote: post #16

To the author of this article: Could you run your node test with "node --trace-gc " turned on? That will output when, and for how long, node's GC is doing it's thing. Anyway, this could be a legit complaint at this point.

--trace-gc will show an endless sequence of mark-sweep/compacts. I explained why that happens in my comment to the original post.

Great comment! Anybody interested should check it out: http://hns.github.com/2010/09/29/benchmark2.html#comment-820...

Re: Node.js memory benchmark confirms V8's GC may not be ready for the server

#28

Post by hannesw »

mraleph wrote: post #26
felixge wrote: post #16

To the author of this article: Could you run your node test with "node --trace-gc " turned on? That will output when, and for how long, node's GC is doing it's thing. Anyway, this could be a legit complaint at this point.

--trace-gc will show an endless sequence of mark-sweep/compacts. I explained why that happens in my comment to the original post.

Yes, --trace-gc shows about 10 Mark-sweeps per second, each taking around 13 ms (no compacts though as far as I could see). But are those ~15% spent in GC are enough to explain the performance?

Re: Node.js memory benchmark confirms V8's GC may not be ready for the server

#30

Post by olegp »

felixge wrote: post #27
mraleph wrote: post #26

Earlier quoted context omitted.

--trace-gc will show an endless sequence of mark-sweep/compacts. I explained why that happens in my comment to the original post.

Great comment! Anybody interested should check it out: http://hns.github.com/2010/09/29/benchmark2.html#comment-820...

It explains why JSON parsing doesn't perform well, but doesn't explain the original benchmark results. Would be great to get a comment from @mraleph or the other V8 guys on that.
Post reply on HN