21–30 of 34 posts
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.
But node.js doesn't have any concurrency. It's single-process, single-threaded and event driven, so by definition it's not concurrent. It's just not blocking. 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.
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.
This is comparing nodejs with Ruby's EventMachine, so where do threads enter the picture? It's been a while since I looked at EM, but if I remember correctly, it's pretty much in the same area as Python's Twisted or node.js, as opposed to something like plain ol' Java threads or Erlang.
Based on the title I assumed it was something like goliath or sinatra/async with rainbows!/thin. Looking at the git repo linked in the article though, I don't believe that is the case.
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.
"The urge to contextualize the data is a good one, but context does not come from empty vertical space reaching down to zero, a number which does not even occur in a good many data sets. Instead, for context, show more data horizontally! "
-- Edward Tufte, October 18, 2001
http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0...
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.
Earlier quoted context omitted.
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).
It's very easy to complain, cast stones, etc. I don't think I've seen a benchmark on HN or reddit where many of the comments were not smug complaints. Yet, I've never seen any of the complainers produce a benchmark with the exception of zedshaw and one other person whose name I've forgotten.
Just because someone posts a benchmark that is obviously flawed, doesn't mean that someone else should be obligated to do their own benchmark as a counter.
These guys didn't ask for node.js to be used in any benchmark.
The onus is on the person who chooses to do a benchmark, and publish the results, to get it right. If they don't get it right, then they are in the wrong and deserve the criticism that they get as a result.
Earlier quoted context omitted.
It's very easy to complain, cast stones, etc. I don't think I've seen a benchmark on HN or reddit where many of the comments were not smug complaints. Yet, I've never seen any of the complainers produce a benchmark with the exception of zedshaw and one other person whose name I've forgotten.
Why should they? Just because someone posts a benchmark that is obviously flawed, doesn't mean that someone else should be obligated to do their own benchmark as a counter. These guys didn't ask for node.js to be used in any benchmark. The onus is on the person who chooses to do a benchmark, and publish the results, to get it right. If they don't get it right, then they are in the wrong and deserve the criticism that…
Earlier quoted context omitted.
Why should they? Just because someone posts a benchmark that is obviously flawed, doesn't mean that someone else should be obligated to do their own benchmark as a counter. These guys didn't ask for node.js to be used in any benchmark. The onus is on the person who chooses to do a benchmark, and publish the results, to get it right. If they don't get it right, then they are in the wrong and deserve the criticism that…
Because it's like complaining about the weather. It doesn't do anything to make things better. I think there's too much negativity on the Internet already.
Earlier quoted context omitted.
Why should they? Just because someone posts a benchmark that is obviously flawed, doesn't mean that someone else should be obligated to do their own benchmark as a counter. These guys didn't ask for node.js to be used in any benchmark. The onus is on the person who chooses to do a benchmark, and publish the results, to get it right. If they don't get it right, then they are in the wrong and deserve the criticism that…
Because it's like complaining about the weather. It doesn't do anything to make things better. I think there's too much negativity on the Internet already.
For example, if these guys were publishing this benchmark as part of a study or argument in a quarterly magazine -- and this was there only opportunity to publish it for the next year or so -- then they would have been far more critical of their own work prior to publishing it. Instead they've quickly thrown together something and pushed it onto the Internet without too much further thought.
So long as it is civil, criticism is fine.