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.
Node.js memory benchmark confirms V8's GC may not be ready for the server
41–43 of 43 posts
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#42It 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…
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#43Earlier 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.