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

11–20 of 43 posts

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

#11

Post by hannesw »

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 thinking) are fair. My intention is just to make people see there's no magic bullet with performance or scalability, and that there are alternatives for server-side JavaScript.

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

#12

Post by amix »

V8 has a very impressive garbage collector (stop-the-world, generational, accurate) and the GC is probably a part the Google team have spent a lot of time tuning and working on as it's one of the harder and most important parts of building a VM...

My guess is that node's GC configuration isn't finely tuned for 25KB structures or maybe the GC is called prematurely.

Some suggestions: try to turn off the GC and re-do the benchmark, try with smaller JSON datastructures, try with different versions of node. Each of these would give more evidence where the problem is.

Btw. in that benchmark: which versions of RingoJS and node.js are used? How much memory does each server use in the end?

Edit: What type of garbage collector does RingoJS/Rhino use - how is the GC configured for RingoJS?

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

#13

Post by xearl »

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 think the main point of this post (and also the edited headline) is that this is not an issue of Node per se, but rather of V8.

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

#15

Post by hannesw »

amix wrote: post #12

V8 has a very impressive garbage collector (stop-the-world, generational, accurate) and the GC is probably a part the Google team have spent a lot of time tuning and working on as it's one of the harder and most important parts of building a VM... My guess is that node's GC configuration isn't finely tuned for 25KB structures or maybe the GC is called prematurely. Some suggestions: try to turn off the GC and re-do th…

Most of these questions are answered in my original, longer post: http://hns.github.com/2010/09/21/benchmark.html.

The JSON I'm parsing is just objects with short string properties (around 10 characters). There's just one longer 25kb JSON string but that is never collected. As to Node configuration, can you provide some specific options to use? I've been asking about this on #node.js (and ryan) and I'm open to any suggestions.

Ringo is running with the server hotspot JVM without any further options.

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

#17

Post by hannesw »

russell_h wrote: post #14

Why does he pin this on the garbage collector?

Just an educated guess. If you're allocating tons of objects and strings and your app gets slow, it's very likely to be the GC. But I don't know V8 well enough to say for sure.

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

#18

Post by felixge »

maushu wrote: post #8
jiaaro wrote: post #4

It seems like node performs better at the bottom of the curve where most of us are likely to be. Can the performance issues be solved by adding hardware? (or spin up more node processes so that each one stays at the bottom of the curve?

It is recommended to use multiple node processes on multi-core servers since node is single-threaded.

That will help with the symptoms, but not with the problem. Having big response-time variations like this is undesirable.

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

#19

Post by xearl »

hannesw wrote: post #15
amix wrote: post #12

V8 has a very impressive garbage collector (stop-the-world, generational, accurate) and the GC is probably a part the Google team have spent a lot of time tuning and working on as it's one of the harder and most important parts of building a VM... My guess is that node's GC configuration isn't finely tuned for 25KB structures or maybe the GC is called prematurely. Some suggestions: try to turn off the GC and re-do th…

Most of these questions are answered in my original, longer post: http://hns.github.com/2010/09/21/benchmark.html . The JSON I'm parsing is just objects with short string properties (around 10 characters). There's just one longer 25kb JSON string but that is never collected. As to Node configuration, can you provide some specific options to use? I've been asking about this on #node.js (and ryan) and I'm open to any s…

Per default, Java 6 uses a generational collector with multi-threaded stop-the-world copying for the young generation and single-threaded stop-the-world mark-sweep-compact for the tenured generation.

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

#20

Post by xearl »

hannesw wrote: post #17
russell_h wrote: post #14

Why does he pin this on the garbage collector?

Just an educated guess. If you're allocating tons of objects and strings and your app gets slow, it's very likely to be the GC. But I don't know V8 well enough to say for sure.

When plotting the response time over time, this educated guess becomes even more solid:

http://earl.strain.at/2010/ringo-node-benchmark/buffer-alloc...

(This uses the very same dataset underlying the "buffer alloc" graph in the original post.)

Post reply on HN