Live data from Hacker News

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

hns.github.com

41–43 of 43 posts

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

#41
post #40
post #36

Earlier quoted context omitted.

I just found out the same. So I guess it must be some intra-VM data shifting? Anyway, I'll update my posting accordingly.

I don't know node.js well enough to even make a guess here. Somebody needs to profile it. Updating your post sounds like a nice idea. It created a lot of confusion among developers.

Updated!

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

#42
post #10
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?

You're interpreting the graph incorrectly. There's no "bottom of the curve", the graph is showing a distribution, not some property over time. A correct reading will e.g. tell you that out of 50'000 requests a total of ~30'000 requests completed in 100ms or less. Or similarly for what you call the bottom of the curve: 5'000 out of 50'000 requests complete in ~25ms or less. This does _not_ state which 5'000 requests t…

ahh... For some reason I thought it was showing request volume

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

#43
post #18
post #8

Earlier quoted context omitted.

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.

Not only that, but one of Node's big selling points has been the supposed flat response time distribution it achieves with a simple 'helllo world' example. Clearly thats not the case once each Node/V8 need to do a real-world amount of work per request.
Post reply on HN