In my experience, Rails and frameworks in PHP are quite slow, and typical uses of databases are quite fast.
I think it boils down to generality. A database is a very specific thing, and the typical usage of the database (e.g. SELECT * FROM products WHERE id=?) can be very highly optimized.
A programming language or framework is much more general, and it is much harder to optimize common cases without losing layers of abstraction.
For example, it would be much faster to return records as arrays instead of ActiveRecord objects. That would probably be much better for certain uses — say, processing of lots and lots of records. It would be worse for most cases, though, and would make Rails that much harder to use.
This is probably exacerbated by the tendency to do everything in the application instead of in the DB (e.g. not using hand built SQL to get aggregate information). That said, it seems like there's been some movement toward shifting some processing back into the DB (e.g. joins).
Yeah, 400 ms spent on average just in Ruby on a modern server is really absurd, though. Think about that - half a second, before anything to do with the database. I try to shoot for sub-100ms avg. total, this would probably drive me insane.
I don't think I've ever managed to write a PHP page that took more than 100ms on average for the PHP alone on a decent server, and it's not from a lack of abuse.
I have no idea where you get 400ms on average. Here's the log for a blog post page of my site. It's a heavy and big page, it's on ruby 1.8.7 and rails 3, and I haven't done anything to make it faster. I could cache most of it rather easily.
Completed 200 OK in 205ms (Views: 168.9ms | ActiveRecord: 23.2ms | Sphinx: 9.6ms)
edit: a couple of notes. This is running on a cheap vps and would be faster on a real server. It would be faster if I used ruby 1.9 as well. If you want to see how fast a bare ruby webserver is then check out this. http://torquebox.org/news/2011/02/23/benchmarking-torquebox/
Performance depends on the application. You are spending 168ms rendering. If the page had a few more partials or some more data, you could be seeing 400ms for that page easily.
Rails view/partial rendering is pretty slow in general.
i know, but as I said, that page is pretty heavy and it's not close to 400ms. It's on a cheap vps and using 1.8.7, And I could easily cache most of it.
I think the some people could have read the comment I replied to and believe that 400ms is somehow normal. It's not.
It sounded to me as if you believed this was typical for a rails site. Maybe I read it wrong, but it isn't typical for a rails app that I've ever done.
Rails has supported joins since forever. However the problem with moving things to the DB is that the DB is very hard to scale while scaling the web app is almost trivial.
The read only parts are not that difficult to scale in the DB. It's the concurrent write load that is really difficult to scale. As long as a single DB server can cope with all the write load, everything is fine. That's like 99.9% of all sites and applications.
I think it boils down to generality. A database is a very specific thing, and the typical usage of the database (e.g. SELECT * FROM products WHERE id=?) can be very highly optimized.
A programming language or framework is much more general, and it is much harder to optimize common cases without losing layers of abstraction.
For example, it would be much faster to return records as arrays instead of ActiveRecord objects. That would probably be much better for certain uses — say, processing of lots and lots of records. It would be worse for most cases, though, and would make Rails that much harder to use.
This is probably exacerbated by the tendency to do everything in the application instead of in the DB (e.g. not using hand built SQL to get aggregate information). That said, it seems like there's been some movement toward shifting some processing back into the DB (e.g. joins).