Alexey, that's an interesting comparison. Your benchmark does almost no work in the node/ruby code itself. Since you used a modern Ruby webserver that is based on lightweight threads rather than processes, it's not too surprising that node is "only" 1.3 times faster under an appreciable but not outrageous load. (:
So you're basically measuring how close you can come to delivering the performance you'd get with async by using modern threads, provided things aren't scaled up too far. Not surprisingly it beats the pants off old school one-connection-per-process model that is still favored in PHP development. It's still slower than a direct async implementation. I bet that if you used Cramp - an async ruby environment that I randomly found with Google, there may be a better one - the performance would be closer to equality. But what you have not really tested is the impact of how much faster v8 is than Ruby, because your code does so little actual work. If you were doing some nontrivial template rendering here, anything that took a decent amount of data crunching, I suspect the results would be different. Thanks, though, for bringing me up to speed on what the threaded model is like in Ruby web development these days. On Tue, Sep 23, 2014 at 3:14 PM, Alexey Petrushin <[email protected]> wrote: >> I've programmed in both sync and async code, and neither is perfect. Node >> basically >> has trade-offs - I get better performance [1] at the expense of a slightly >> cumbersome programming model. > > I compared Node.js with "slow" Ruby on Rails and the result is that node.js > is only 1.3 times faster. > (maybe there's an error in my benchmark, but I can't find it so far). > > http://alex-craft.com/blog/2014/ruby-on-rails-vs-nodejs > sources https://github.com/alexeypetrushin/web-frameworks-benchmarks > >> Your sync version doesn't handle errors at all > > I knew that someone would point to it. But actually it does handle errors. > The whole request thread wrapped with try/catch (implicitly, inside of web > framework code) - and it does handle errors. > In node.js it's impossible to handle errors in such a way implicitly because > there's > no context there. You don't know which error belongs to which request and > has to do it manually. > > > On Tuesday, 23 September 2014 19:50:01 UTC+4, Matt Sergeant wrote: >> >> >> On Tue, Sep 23, 2014 at 7:29 AM, Alexey Petrushin <[email protected]> >> wrote: >>> >>> Ha-ha, very good example, compare this async version it with the sync >>> version below, and tell me that there's no problem with >>> callbacks """if you know how to deal with it""" :D >>> >>> Not saying that in even such a simple code it's extremely >>> easy to make small errors like missing `else` statements etc. >>> >>> Also it doesn't preserve the call stack - so when you see error in >>> console >>> you would have no context and no idea what happened... >>> And it still doesn't catch the sync errors... >>> And some of callbacks can be fired twice... >>> And with streams there are lots of events fired and should be properly >>> handled... >>> >>> And still many insist that it is "not a problem". >> >> >> I don't insist it's "not a problem", but programming is always going to >> present challenges. I've programmed in both sync and async code, and neither >> is perfect. Node basically has trade-offs - I get better performance [1] at >> the expense of a slightly cumbersome programming model. I could go even more >> cumbersome for even more performance if I switched to C++ or Java. But I'm >> OK with where Node takes me for now. >> >> The flip side with sync code of course is that sync programming is often a >> lot harder than people make it out to be. Your sync version doesn't handle >> errors at all, for example. Error handling is very language/environment >> specific and often an area of huge neglect. One thing Node got right was to >> always use the "error first" callback approach, that makes things like >> Streamline and Async.js possible. It's not perfect but all programming is >> trade-offs. >> >> Matt. >> >> [1] Whoever was arguing that Ruby and/or Rails has equal performance >> obviously has never ported a large project from Rails - I have and the >> performance difference is staggering > > -- > Job board: http://jobs.nodejs.org/ > New group rules: > https://gist.github.com/othiym23/9886289#file-moderation-policy-md > Old group rules: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > --- > You received this message because you are subscribed to a topic in the > Google Groups "nodejs" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/nodejs/wBAJhYOzjqQ/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/nodejs/ef189a34-c7ae-49ab-97c9-48035cea8bd0%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- THOMAS BOUTELL, DEV & OPS P'UNK AVENUE | (215) 755-1330 | punkave.com -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAORXhGKgOXG7eEof4c5rpYjLR_rBisUOKU9njk0cRY4ZXhAgng%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
