
Concurrency in Ruby almost as good as Node.js - rgbrgb
http://openhood.com/ruby/node/heroku/sinatra/mongo_mapper/unicorn/express/mongoose/cluster/2011/06/14/benchmark-ruby-versus-node-js/
======
desireco42
I just can't resist, Serbs have saying 'almost is what makes girl unhappy' :).

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.

------
mrinterweb
I would be interested to see how the unicorn variant, rainbows, would
benchmark in this test. Rainbows seems much better suited for high concurrency
applications because it utilizes fibers for concurrency as well as worker
processes. <http://rainbows.rubyforge.org/> Also after looking at the sinatra
app's code, I believe all requests to MongoDB are going to be blocking. For
the comparison to be more fair, the ruby app should be written to take
advantage of Goliath, em-synchrony, event machine, or another non-blocking
ruby fiber based option. Until the ruby app is non-blocking, this comparison
is apples to oranges.

------
maxdemarzi
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.

~~~
cromulent
I thought Tufte was OK with non-zero baselines:

"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...](http://www.edwardtufte.com/bboard/q-and-a-fetch-
msg?msg_id=00003q)

~~~
maxdemarzi
A non-zero baseline is fine in some cases (line chart of the temperature of a
person with a fever for example), but the issues here were multiple charts at
varying Y scale starting points, and bar size comparisons of a property that
we do want to go to zero (zero failures).

------
ianloic
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.

~~~
jshen
[http://stackoverflow.com/questions/1050222/concurrency-vs-
pa...](http://stackoverflow.com/questions/1050222/concurrency-vs-parallelism-
what-is-the-difference)

------
kevingadd
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.

~~~
jshen
I await your proper and full analysis, or a link to one.

~~~
moe
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).

~~~
jshen
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.

~~~
RuadhanMc
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 they get as a result.

~~~
FooBarWidget
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.

~~~
RuadhanMc
There is too much negativity on the Internet, but there's also too much of
just about everything else. The ease of publishing on the Internet means that
people don't think too critically about their work prior to publishing it.

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.

~~~
jshen
I don't think the comment I originally responded to was particularly civil. It
was quite smug.

------
rockarage
This is not a Ruby vs Node.js benchmark because Node.js is still a layer above
the V8 Javascript engine. Moreover Node.js was optimize for things like
concurrency and this is similar to what eventmachine is optimized for. The
difference is node.js makes the event model a language construct. I think it
would have been better to use eventmachine but you did not because:

> _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.

------
chaostheory
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.

~~~
mhd
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.

~~~
stock_toaster
I don't actually even see eventmachine in there, aside from a remark about
having tried it in the opening introduction. Seems it is just comparing node
with sinatra+mongomapper running under thin or unicorn.

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.

------
tszming
Even if you are right, your title should be "Concurrency in Ruby almost as
good as Node.js ON Heroku"

------
dreamdu5t
Requests/sec is not a good benchmark, especially considering how node.js
handles streaming.

For example, if he tested a 1 meg stream of chunked data being served on
request, the node.js numbers would be very different.

