Concurrency in Ruby almost as good as Node.js
openhood.com
Concurrency in Ruby almost as good as Node.js
1–10 of 34 posts
Re: Concurrency in Ruby almost as good as Node.js
#2Hey, 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.
Re: Concurrency in Ruby almost as good as Node.js
#3This 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.
Re: Concurrency in Ruby almost as good as Node.js
#4I 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.
Re: Concurrency in Ruby almost as good as Node.js
#5This 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.
Ol Ed will kill kittens like nothin. I've seen him do it. He learned it from Napoleon.
Re: Concurrency in Ruby almost as good as Node.js
#6This 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.
Pffff, anyone who doesn't measure things on a scale of 8747-41947 is a troglodyte.
Re: Concurrency in Ruby almost as good as Node.js
#7Yes 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.
Re: Concurrency in Ruby almost as good as Node.js
#8This 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.
Yeah, the graphs are misleading because of the varying Y scale.
I do like the conclusions section, though. It presented some insightful analysis of dyno/worker efficiency
>It could be that I’m benchmarking from only 1 server but I’ve seen almost no difference between having 40 dynos or 60. You’ll see one when you receive the bill so be cautious, especially if you use an auto-scale tool.
>The same applies to node with cluster, you can do more with 15 dynos running cluster with 3 workers than with 60 dynos of node alone (for a quarter of the price!).
Re: Concurrency in Ruby almost as good as Node.js
#9Hey, 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.
Re: Concurrency in Ruby almost as good as Node.js
#10Yes 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.
Working with threads in the context of a web request is not hard.