Node.js memory benchmark confirms V8's GC may not be ready for the server
1–10 of 43 posts
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#2Has anyone done any experiements with node.js and Jägermonkey? They’re getting pretty close to V8 in speed ( http://arewefastyet.com/ ) and might prove better for server use (utter conjecture on my part).
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#3Has anyone done any experiements with node.js and Jägermonkey? They’re getting pretty close to V8 in speed ( http://arewefastyet.com/ ) and might prove better for server use (utter conjecture on my part).
From looking at the code it seems that node.js is very tied to V8.
It would be a lot of work to abstract the js core.
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#4It 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?
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#5Has anyone done any experiements with node.js and Jägermonkey? They’re getting pretty close to V8 in speed ( http://arewefastyet.com/ ) and might prove better for server use (utter conjecture on my part).
My understanding is that the Xmonkeys are not nearly so amenable to embedding as node. There are some server implementations of older monkeys, though:
* whitebeam http://whitebeam.org/, which to my surprise appears to be not actually dead yet.
* jaxer http://jaxer.org/
* couchdb
But none of these seem to be low level enough to make a reasonable comparison.
Flusspferd http://flusspferd.org/ seems most like node, but using spidermonkey (circa Firefox 3.5, it seems, but actively maintained, so there's hope for future enhancements). Unfortunately, it doesn't yet seem to have all the handy web serving stuff that node has, so probably still not useful for a competitive benchmark.
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#6Has anyone done any experiements with node.js and Jägermonkey? They’re getting pretty close to V8 in speed ( http://arewefastyet.com/ ) and might prove better for server use (utter conjecture on my part).
I talked with Brendan Eich in New York after JSConf.eu and he was suggesting they might be looking at porting the V8 API to Jägermonkey after they release it so that it can run Node.
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#7I 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.
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#8It 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.
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#9I 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.
Agreed, node is very fast.
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#10It 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 that were, and in particular it does _not_ imply that the _first_ 5'000 requests are faster. For this you'd have to plot response time over time.