11–20 of 34 posts
This is great work but...please redo the charts to start at Zero and end at 50,000 to keep things consistent and prevent Edward Tufte from killing a kitten if he ever sees your charts.
Yes the nodejs concurrency model takes some time getting used to, but working with threads is much harder imo. Raw speed benchmarks don't do enough to give a full picture.
Yes the nodejs concurrency model takes some time getting used to, but working with threads is much harder imo. Raw speed benchmarks don't do enough to give a full picture.
Hey, look, requests/s on a synthetic benchmark. Let's not look at things like thread safety, resource consumption, average/best case/worst case latency, quality of available libraries and their support for concurrency, or code quality/maintainability issues. Meh. At least he provided the source code and plenty of data. That's cool.
I await your proper and full analysis, or a link to one.
Whatever the author is measuring here, it's most certainly not "node" vs "ruby". This should be obvious when you look at the test-apps that he's using (which involve mongodb and serialization).
> At first I tried to compare bare node.js against eventmachine_httpserver. It did quickly became obvious that this kind of micro-benchmark wasn’t going to be very helpful in deciding which one to choose.
Your first observation was the correct one. The best thing to do is just pick a language and go with the best tools available.
For example, if he tested a 1 meg stream of chunked data being served on request, the node.js numbers would be very different.
Yes the nodejs concurrency model takes some time getting used to, but working with threads is much harder imo. Raw speed benchmarks don't do enough to give a full picture.
number_of_threads * thread_stack_size = sadface.jpg (when trying to use threads to handle lots of connections)
On more serious note, ruby is definitely better when it comes to richness of available libraries which is what node is missing. I think in real life node can handle more, I heard that issues with memory leaking are solved, probably uses less memory as well. I agree with conclusion that both are more then capable or handling async problems, I would use event machine on ruby end, this whole example seems flawed a bit. Anyhow, thanks for posting your results.
Earlier quoted context omitted.
I await your proper and full analysis, or a link to one.
I don't think we are required to provide a better analysis in order to point out the problems with a flawed one. Whatever the author is measuring here, it's most certainly not "node" vs "ruby". This should be obvious when you look at the test-apps that he's using (which involve mongodb and serialization).
Also, was someone really trying to run performance benchmarks on a shared machine running on a VM and expecting to get anything meaningful out? Really? Like really? I'm embarrassed for you.