Can a Rails app be slow enough that it becomes the bottleneck, not the db?

Usually, accessing a database tends to be the most cos开发者_如何学Gotly operation in terms of time.

However, since Ruby is among the slowest executing languages (with rails representing an abstraction built on top of an already existing abstraction), do rails apps tend to perform slower than (or as slowly as) most queries to the db?

This is a really subjective question, but in short, yes, of course it can become more of a bottleneck than the DB, depending on your core business concerns. If, say, the only reason you have a database is to require a login, and therefore only make one call to the users table, but your website is all about image processing and you do lots of computationally expensive stuff, then ruby will be more of a concern to you than the database.

The age old idea that you should pick the right tool for the job will never fail to be true.

I don't have much experience on this topic, as I don't do Rails development any more. However, Aaron "tenderlove" Patterson gave a talk "ZOMG WHY IS THIS CODE SO SLOW?" (slideshare, confreaks video), where he talked about ActiveRecord previously being slow because the Ruby implementation used to be sub-optimal.

Yes.

A stupid but true example will be...

def index
  @thing = Thing.find_by_something_not_needed params[:something_not_needed]
  unless something_happens do
    sleep
  end
end

def something_happens; nil; end

Now imagine you were doing some complex logic - such as image processing, or maybe an extraneous stab at the travelling salesman problem with substantial data - that could be modeled by the death loop I have in my silly example. Other factors may be external web requests that just dont go well.

Rails is already the slowest framework among the rest of the 'active' Ruby frameworks (Camping, Sinatra, Merb, Padrino, Ramaze). I found a recent 'unscientific' benchmark: http://pastie.org/2294509 (benchmark source padrino framework's github repository) that provides some results.

The slowness may not manifestate itself that much in production (It probably shouldnt be the cause of a bottleneck), but you will surely experience it while developing applications: Extremely slow boot times, slow rake tasks, very slow test suites, high memory footprint.

This is a compromise. Rails is feature rich and has been around for a long time with a large, active community.

Unfortunately the situation may not improve as with every new Rails version the framework grows larger, with additional layers of abstraction that affect speed. This is pure speculation on my side, but judging by the user base, we won't see any drastic changes to Rails itself to alleviate these problems. The last game changing version 3 has brought a lot of long sought improvements, but they were more of improvements to the modularity of the framework, rather than improvements to performance.

This question is like asking "Can a Porsche be slowed down to a slower speed than a Pinto?".

You should judge your performance in average millisecond response times. For example, if a page in your app takes on average 100ms to sun, then in theory, you can get 10 request per second. If you investigate and determine that 100ms is because 60ms is being spent parsing some string...a string that can be reduced or even ignored, then the problem really isn't Ruby or Rails is it?

Ruby/Rails is fast enough for most web applications. I think you are trying to convince yourself to use something other than Rails. If you don't want to use Rails, that is fine. But don't abandon Rails because it COULD be slowed down by bad programming. This is true of any language.

Instead, embrace Rails (or Sinatra or Padrino or Django) and have fun. Worry about performance when performance is an issue.