4 ms·

Making Rails 12X Faster

67 points by sant0sk1 18y ago

sfamiliar 18y ago
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.
- bfioca 18y ago
  Actually there's already mysql support in the mysqlplus driver. http://www.espace.com.eg/neverblock/blog/2008/08/28/neverblock-mysql-support/ http://www.espace.com.eg/neverblock/blog/2008/08/28/neverblo... 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.
- aaronblohowiak 18y ago
  it is coming soon. rails 2.2 is going to be multithreaded. ruby 1.9 has not been released (it is still a dev release at this point.)
deleted 18y ago
[deleted]
- Locke 18y ago
  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.
irrelative 18y ago
This is certainly good news for beginners, but for serious scaling, rails itself is almost never the problem. 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.
- jwilliams 18y ago
  Yeah... Also, my natural instinct when I saw the article was to think "scale and performance aren't the same thing". Not saying this isn't a good thing in itself, but scale means a lot of other things.
- anotherjesse 18y ago
  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.
  - irrelative 18y ago
    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.
- vegai 18y ago
  >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.
tdavis 18y ago
Not to produce sour grapes here, but the Twisted framework has had async db adapters for quite a while now. Still, good for Rails. I will be much less annoyed by Ruby/Rails adoption when (1) Rails performs better and (2) the Ruby interpreter doesn't suck.
- jon_dahl 18y ago
  You find it annoying that other people prefer a certain technology?

67 points by sant0sk1 18y ago

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.

bfioca 18y ago
Actually there's already mysql support in the mysqlplus driver. http://www.espace.com.eg/neverblock/blog/2008/08/28/neverblock-mysql-support/ http://www.espace.com.eg/neverblock/blog/2008/08/28/neverblo... 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.
aaronblohowiak 18y ago
it is coming soon. rails 2.2 is going to be multithreaded. ruby 1.9 has not been released (it is still a dev release at this point.)

deleted 18y ago

[deleted]

Locke 18y ago
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.

irrelative 18y ago

This is certainly good news for beginners, but for serious scaling, rails itself is almost never the problem. 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.

jwilliams 18y ago
Yeah... Also, my natural instinct when I saw the article was to think "scale and performance aren't the same thing". Not saying this isn't a good thing in itself, but scale means a lot of other things.
anotherjesse 18y ago
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.
- irrelative 18y ago
  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.
vegai 18y ago
>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.

tdavis 18y ago

Not to produce sour grapes here, but the Twisted framework has had async db adapters for quite a while now. Still, good for Rails. I will be much less annoyed by Ruby/Rails adoption when (1) Rails performs better and (2) the Ruby interpreter doesn't suck.

jon_dahl 18y ago
You find it annoying that other people prefer a certain technology?