Rails 3 Performance - Not Good Enough
11–20 of 142 posts
Re: Rails 3 Performance - Not Good Enough
#12I can't believe that in a modern web app, most of the time wouldn't be spent in the database, those graphs floored me. Other than expanding templates, what in the world is Rails doing with that time??
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).
Re: Rails 3 Performance - Not Good Enough
#13For our application that meant bringing 1 of 3 application servers down and slowing things down in general. So we're stuck with 3.0.5.
From what I understand the Rails community has declared 1.8.x as a thing of the past (tbf it IS a thing of the past. But in a non-perfect world migrations our not always easy). This may be a good thing (it forced us to march towards 1.9.2) but I'm sure it has caused a lot of problems.
Re: Rails 3 Performance - Not Good Enough
#14I can't believe that in a modern web app, most of the time wouldn't be spent in the database, those graphs floored me. Other than expanding templates, what in the world is Rails doing with that time??
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…
Re: Rails 3 Performance - Not Good Enough
#15Earlier quoted context omitted.
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…
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.
Re: Rails 3 Performance - Not Good Enough
#16https://github.com/rails/rails/commit/86acbf1cc050c8fa8c74a1... For our application that meant bringing 1 of 3 application servers down and slowing things down in general. So we're stuck with 3.0.5. From what I understand the Rails community has declared 1.8.x as a thing of the past (tbf it IS a thing of the past. But in a non-perfect world migrations our not always easy). This may be a good thing (it forced us to ma…
https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/...
https://gist.github.com/919428
https://github.com/rails/rails/commit/a3639be4ed5e89b59c4ad0...
The commit mostly fixes that particular issue (and is included in 3.0.7), but as the article point out Rails 3 AR performance still needs quite a bit of work.
Re: Rails 3 Performance - Not Good Enough
#17But there are people who have convinced themselves that as long as it scales out, it doesn't matter how many servers you have to run. And if the reason is that something that's known statically is checked billions of times at runtime they don't care.
For a framework, the concept of premature optimization makes no sense.
Re: Rails 3 Performance - Not Good Enough
#18I can't believe that in a modern web app, most of the time wouldn't be spent in the database, those graphs floored me. Other than expanding templates, what in the world is Rails doing with that time??
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…
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.
Re: Rails 3 Performance - Not Good Enough
#19I think the real problem with Rails and similar frameworks is the culture of not giving a shit about performance. I would never ever release a new version of anything that is significantly slower than the previous one. It's simply a bug in my view. But there are people who have convinced themselves that as long as it scales out, it doesn't matter how many servers you have to run. And if the reason is that something t…
What if the new thing had 100x more (useful) features, should it still be as fast?
Performance is a trade-off and sometimes it's worth compromising.
Re: Rails 3 Performance - Not Good Enough
#20I think the real problem with Rails and similar frameworks is the culture of not giving a shit about performance. I would never ever release a new version of anything that is significantly slower than the previous one. It's simply a bug in my view. But there are people who have convinced themselves that as long as it scales out, it doesn't matter how many servers you have to run. And if the reason is that something t…