Even for large sites this (combined with other rails/ruby improvements) is a huge gain.
Because each rails app server can only handle a single request at a time, you have to spawn more and more instances of rails. Each of these instances consume 50-200MB of ram. Being able to have a single app server per server means I can stop spending so much on ram (or use it for other purposes).
So at a large scale, this will be a large impact because it will reduce the number of mongrels/thins/... you have to run.
That's correct. My understanding is (having never been there myself) that if you're running a large site, you're going to have to throw hardware at a scaling problem -- that said, if just hardware solves your problem, you're in great shape.
>This is certainly good news for beginners, but for serious scaling, rails itself is almost never the problem.
I wish this myth would just die. Just because David Hansson and nearly every other person in the Rails community keeps saying and saying that, it does not make it true.
railsenvy podcast mentioned this, and that mysql support would be coming 'soon', but since this is ruby 1.9 only, it's not a terribly useful thing until there exists a rails version that fully supports 1.9.
It's supposed to be 1.8.6 compatible but neverblock isn't, I don't think - so I'm not sure what the advantage of this alone would be. I'd like to know, though.
You're reading it wrong. He used 10 requests to illustrate that they would be handled in parallel (vs sequentially as in stock rails). His actual benchmarks show many thousands of requests being processed.
* This was originally in response to a comment asking if the benchmark only consisted of 10 requests.
The way this test was done was by making postgres sleep between requests -- in reality, postgres would become the bottleneck fairly quickly.
Not trying to rain on anyone's parade though -- it's great news for the small to medium sized rails-powered site.