7 ms·
Rails 3 Performance - Not Good Enough
- fleitz 15y agoI'd be interested to know if they are running Rails 3 on 1.9.2 or 1.8.7.
- simonsarris 15y agoThey said they were using ruby enterprise edition (aka a 1.8.6 branch)
- fleitz 15y agoInteresting, IIRC Rails 3 works best with 1.9.2 I'm going to run the benchmarks on 1.9.2 vs. 1.8.7 and see how they fare.
- raid5 15y agoThe article mentions, "REE 2011.03, which is Ruby 1.8.7 patchlevel 334". Not sure if this was a recent edit or not.
- Plugawy 15y agoree is 1.8.7 - Rails3 doesn't work with anything below 1.8.7
- patrickaljord 15y agoHe says he's using ree so probably 1.8.x.
- deleted 15y ago[deleted]
- meltzerj 15y agoIt'd be interesting if anyone could figure out what about AR 3.0.5 vs. AR 2.3.2 is causing this performance decline.
- danielparks 15y agoThe benchmark was done using REE. Out of curiousity, I tried it with MRI 1.8.7, MRI 1.9.2, and REE 1.8.7. Results are best out of three: user system total real rails3-1.9.2 2.240000 0.200000 2.440000 ( 3.127072) rails2-ree 2.530000 0.290000 2.820000 ( 3.578471) rails2-1.8.7 2.920000 0.210000 3.130000 ( 3.876215) rails3-ree 3.140000 0.250000 3.390000 ( 4.111465) rails3-1.8.7 3.560000 0.220000 3.780000 ( 4.505166) Of course, the author was looking into a specific problem — this doesn't mean that Rails 3 on MRI 1.9.2 is faster than Rails 3 on REE. Run on an iMac9,1 with a 2.66 GHz Core 2 Duo. uname -a: Darwin Roy.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386 I disabled spotlight, but who knows what other processes might have spawned in the middle of the benchmark. Your mileage may vary.
- joevandyk 15y ago1.9.2 has some slow startup problems with rails 3 -- I don't believe your benchmark measures startup time.
- joevandyk 15y agoNot sure why this was downvoted. In 1.9.2 (p180 and head), my rails 3 application starts in 26 seconds. With REE 1.8.7, it starts in 8 seconds or so.
- danielparks 15y agoIt's aimed at an issue with ActiveRecord. Like I said, it doesn't mean that Rails 3 on MRI 1.9.2 is faster than Rails 3 on REE. Also, just to be clear, I'm not the author of the linked post or the benchmark.
- stiff 15y agoThere clearly still are performance problems in Rails 3.0.x that aren't fixed. I am just now in the process of switching an application to Rails 3 and I have recently spent 5 days of hard work trying to investigate a big performance drop after the migration (under a different environment: Ruby 1.9.2 and PostgreSQL). I ended up finding two big performance issues in Rails PostgreSQLAdapter: https://github.com/rails/rails/issues/398 https://github.com/rails/rails/issues/398 https://github.com/rails/rails/issues/485 https://github.com/rails/rails/issues/485 What they and everyone else experiencing performance problems should do, is to find one action that has the biggest performance difference between running under Rails 2 and Rails 3 and then profile it - easiest way is by wrapping the action in an around filter and using RubyProf. If there is a obvious performance problem somewhere, you will most often see a method that has a really huge number of calls and %self% time in comparison to all the others. Then you have to figure out what in detail happens - I ended up doing this by putting "begin; raise StandardException.new; rescue => e; puts e.backtrace; end;" into the "hot" methods to get call stacks and then went on to read the code involved.
- xpaulbettsx 15y agoI 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??
- danielparks 15y agoIn 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).
- FooBarWidget 15y agoRails 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.
- fauigerzigerk 15y agoThe 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.
- ericd 15y agoYeah, 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.
- banditaras 15y agohttps://github.com/rails/rails/commit/86acbf1cc050c8fa8c74a10c735e467fb6fd7df8 https://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 march towards 1.9.2) but I'm sure it has caused a lot of problems.
- sgrytoyr 15y agoThat commit made certain pages of my app about 10 times slower. This was such an appalling performance degradation that I had to do some digging: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/6695 https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/... https://gist.github.com/919428 https://gist.github.com/919428 https://github.com/rails/rails/commit/a3639be4ed5e89b59c4ad0154d44f58e3e48d484 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.
- pilif 15y agoJudging by the comments on that commit and the comments in this HN post, I would say that many of the performance regressions are only happening under ruby 1.8.x. By this time, I wonder what the rails developers should spend their time with: making the framework better for people running the current version of the language or fixing performance problems due to shortcomings of the old version? If you can't upgrade to 1.9 and the performance of rails 3 isn't good enough for you to upgrade rails, why don't you just stay with 2.3 and upgrade once you are ready to move to ruby 1.9? That way your unwillingness to upgrade ruby doesn't "waste" the time of the rails developers by causing them to fix issues that don't even apply to more and more people over time. Note: i'm talking about regressions that only affect 1.8
- nirvdrum 15y ago
- fauigerzigerk 15y agoI 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 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.
- comice 15y agoYou'd never release a new version of anything that was slower? 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.
- fauigerzigerk 15y agoIf I'm writing a framework on which others depend in ways I cannot entirely foresee, then the old features _must_ perform as well or better than before. No compromises.
- lhnz 15y agoOut of interest, what language is your framework for? I'm seriously thinking of stopping using PHP because of the weight of the frameworks -- at least on Python there are microframeworks in which I am not left with a massive bottlenecks on the simplest Hello World page. Sure, you can scale but it's becoming ridiculous that I am forced to be so frugal with processor intensive tasks in the rest of the web application just because of the framework.
- fauigerzigerk 15y agoMy own framework and ORM writing days are long past and the software I write nowadays has very different constraints (data/text mining). I totally share your sentiment about having to be frugal because of wasteful frameworks. My approach is to prefer libraries over frameworks. I start out using the most bare-bones configuration possible (no frameworks, no ORM, no CMS, etc) and then I selectively add well maintained libraries created by people whose attitude I understand. I think code reuse is generally overrated, particularly when it comes to the rather trivial things that web frameworks do. This is probably not very helpful to you. I apologize.
- nametoremember 15y agoI DON'T want to start a flame war or anything, but how does this hold up to Django and PHP frameworks like cakephp and Zend?
- justincormack 15y agoWhy dont you meeasure it? His microbenchmark basically measures the time to do 10000 database round trips to extract a field. So long as you dont overoptimise and request all the data in a single transaction.
- nametoremember 15y agoHmm, I've never benchmarked anything before but I guess I will give it a go. (After my exams!)
- tluyben2 15y agoOfftopic; when opening this page I tried to clean my screen as there seemed to be gunk on it. Apparently it is the site design.
- swaits 15y agoWhining about free, open source software. Fix it or move on.
- aneth 15y agoI've been a Rails dev for 5 years. I'm frequently considering leaving for another framework because of one thing: bootstrap time. Starting a test or server on my dev machine takes 20-30 seconds. Particularly with tests, this is a huge problem for doing proper TDD, particularly when you are trying to use tests to track down a bug. In that 20-30 seconds, I often console myself that we no longer need to print punch cards and wait a whole day, but that's little consolation when node.js starts up in under a second. There are hacks and fixes to this like spork, but none of this should be necessary. The performance issues are not debated in the open enough. I don't understand how those startup times are acceptable to anyone, but I rarely get responses when I ask questions about it. http://stackoverflow.com/questions/5738443/why-is-rails-bootstrap-so-slow-and-what-can-i-do-about-it http://stackoverflow.com/questions/5738443/why-is-rails-boot... UPDATE: I have the latest top of the line Macbook Air - 2.13 Ghz Core 2 Duo with SSD. I have other issues with Rails, but this is the only potential deal breaker. (I tend toward functional clarity instead of "human" readability in the magic debate, while most "Rubyists" would rather pollute the namespace (e.g. metawhere) and create 100 line method_missing calls to make one command slightly prettier aesthetically. And Cucumber - ugh what a ridiculous contraption that is.)
- jpr 15y agoHow often do you need to endure that 20-30 second startup time? Is it every time you change anything?
- joevandyk 15y agoDuring deploys, running a test, configuration changes, starting anything that loads the whole rails environment.
- aneth 15y agoPretty much ANYTHING you do. Start a console, start a server, run a test, migrate your database, run a rake task. It's a huge productivity killer for me. And as other comments have stated, it's surprising this issue is not discussed more.
- 15y ago
- strmpnk 15y agoInteresting, though I no longer use ActiveRecord in my largest app because of how slow it is (even in Rails 2). Try checking the overhead of instantiating (no save or db lookup) a simple model instance with 2 fields for example. If you manage to avoid that, you've beaten the slowest parts. The view engine is also slow but I tend to do rendering in the browser these days so that barely matters too me. If you are careful, it is very realistic to have response overhead from rails hover around 1-2ms for simple things and maybe up to 10-20ms for the most complex business logic (expensive validations). It's kind of odd that people who care about performance assume they have to take the whole package as is.
- cmelbye 15y agoWhat would you suggest to use instead of ActiveRecord in a Rails 3 app?
- reedlaw 15y agoI would think something like Mongoid might be a contender (no idea how they actually compare).
- strmpnk 15y agoIt depends on the data. For one app I've written my own CouchDB driver which, as slow as CouchDB is known to be, seems to kill most AR equivalent code. That's pending release as soon as it's stable. Generally speaking, I think AR's problem isn't really an API one, it's a great interface. It's that it's implementation is far too clever and would benefit quite a bit from narrowing supported driver styles and removal of some old APIs that really hurt more than help. There could also be better control over opt-in on some behaviors that start adding up in overhead (i.e. change tracking keeps a lot of garbage around).
- cldwalker 15y agoIf the author is really concerned about rails3 performance has he opened a ticket with his specific case? tenderlove has been addressing AR performance issues in rails3 for quite some time.
- joevandyk 15y agoWith Rails 3 in development mode, one of my pages loads in 2 seconds. On 2.3, it loads in about 0.6 seconds. :( Rails 3 is awesome, except for the performance issues. I'm not sure how to go about looking into it. When I profile, the bulk of the time is spent garbage collecting apparently.
- sgrytoyr 15y agoI just ran a simple test on every version of ActiveRecord that I could get running (standalone), using both Ruby 1.8.7 and 1.9.2, and graphed the numbers. Here is the result: http://jsfiddle.net/2bUb5/ http://jsfiddle.net/2bUb5/
- nirvdrum 15y agoInteresting. I wonder if REE is really the savior for the article author then.