Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails 3 Performance - Not Good Enough

blog.tstmedia.com

Post reply on HN
Print view View original

101–110 of 142 posts

Re: Rails 3 Performance - Not Good Enough

#101

Post by joevandyk »

towelrod wrote: post #38
fauigerzigerk wrote: post #17

I 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…

The problems here are manifesting on Ruby 1.8.7, but not 1.9.2. There have been big performance problems found with 1.8.7, for example in this issue: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/... What was originally a performance optimization on 1.9.2 caused a terrible slowdown on 1.8.7. It was reported and fixed within two days. Does that still fit into your "not giving a shit about performance" cr…

Here's what perftools.rb gives me for a view-heavy page on 1.9.2-p180 with Rails 3:

http://dl.dropbox.com/u/6607107/dev.tanga.gif

46% of the time is spent garbage collecting.

Re: Rails 3 Performance - Not Good Enough

#102

Post by carbon8 »

aneth wrote: post #98
carbon8 wrote: post #96

Earlier quoted context omitted.

"I don't think I should forgo reusing community code to reduce start times." Using too many gems is an problem for a lot of reasons, though. You are introducing dependencies that you then need to manage and update, they often do more than you need to while being harder to maintain (you might end up with a bunch of forks in your gemfile as things get outdated), they are sometimes invasive and will require big rewrites…

True that gems often do more than I need, but should I? 1) Write my own authentication code 2) Write my own ical feed code (just added this in about 2 hours using ri_cal, which has way more features than I need) 3) Write my own code to inline css in email 4) Write my own Facebook API library 5) Write my own admin interface 6) Write my own SCSS and HAML processors 7) Write my own file attachment and processing code 8)…

That's only 9 libraries, and that shouldn't be enough to cause your load times to reach 20-30 seconds.

Also, since you asked :-) I would question #5. Auto admin libraries (and this applies to multiple languages and frameworks) are generally heavy, too general and have code hidden away in the library. In contrast, banging out crud views and controllers in a locked-down namespace is easy, only relies on same dependencies as the rest of the app, can be customized for the specific business needs and all the code is in one obvious place.

Re: Rails 3 Performance - Not Good Enough

#103

Post by carbon8 »

mrj wrote: post #85
[deleted] wrote: post #83

Earlier quoted context omitted.

[deleted]

That's not the dev server, which is able to start and reload pretty fast. That post is complaining about the startup time for loading several pre-forked Python VMs on the first request. That's pretty much a production problem. It's somewhat common to see "warmup" scripts that make sure all the VMs start. The OP was talking about development time.

"That's not the dev server, which is able to start and reload pretty fast...That post is complaining about...a production problem."

The issue is actually that it takes time to load the application code and dependencies, something that applies to Django, Rails and just about any similar framework, regardless of whether it's the production or development environment. In general, the production environment will actually be faster at this.

Just to clarify the context to future readers, I deleted by post because I wasn't interested in discussing django, but since you responded I'm addressing it. My original post pointed out that in my experience it indeed does take time to load django and linked to this post: http://stackoverflow.com/questions/1702562/speeding-up-the-f...

Re: Rails 3 Performance - Not Good Enough

#104

Post by philjackson »

aneth wrote: post #53

I'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 card…

I was at the BBC working on a large Perl codebase which was a fairly typical Catalyst/DBIx::Class stack. It had thousands of tests which thanks to the foolish way we loaded reference data and pre-populated memcache etc. had the test suite running for 3 hours. As you can imagine, it was a nightmare for TDD and indeed for large merges (by the time you've run tests trunk would have inevitably changed). We never fixed it thanks to a combination of lazyness and a case of "it's legacy code, won't be around much longer" syndrome.

http://qwerly.com runs a tight and fast Node.js stack at the front-end with a test suite that takes less than a second to run (a few hundred assertions). I'll dedicate much time to the framework around it's tests and make sure it's never slow.

Re: Rails 3 Performance - Not Good Enough

#105

Post by reedlaw »

cmelbye wrote: post #80
strmpnk wrote: post #58

Interesting, 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 caref…

What would you suggest to use instead of ActiveRecord in a Rails 3 app?

I would think something like Mongoid might be a contender (no idea how they actually compare).

Re: Rails 3 Performance - Not Good Enough

#106

Post by carbon8 »

joevandyk wrote: post #99
carbon8 wrote: post #93

Earlier quoted context omitted.

"autotest or watchr doesn't help startup times -- I'm not sure why you mentioned that here." If you use autotest or watchr you aren't starting up the environment very frequently.

I'm not sure why you think that. Unless you use spork or something that preloads the rails environment then forks it on every test run, autotest/watchr will boot the whole rails environment from scratch on each run.

You're right. I'm distracted by the reported 20-30 second environment load time for each test when it only takes about 7 seconds for my tests to start with autotest in my current pretty large app on an older MBP.

Re: Rails 3 Performance - Not Good Enough

#108

Post by bphogan »

moe wrote: post #49
fauigerzigerk wrote: post #17

I 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…

culture of not giving a shit about performance Yes. On top of that the ruby ecosystem also seems to attract a certain class of programmers who simply don't know how their magic ruby code translates to CPU, I/O and memory operations. My pet example is a certain popular rails auth framework that hits the database for every single request, to look up tokens that could simply be baked into the cookie. But there are plent…

I've never ever gotten why people get so mad that the database gets hit on every request. It's going to get hit anyway on every request for something else. I've seen how easy it is to break into systems that don't re-auth the user on each request. I guess I just feel like people spend an inordinate amount of time worrying about database performance. A single select from a single table shouldn't be a performance bottleneck. It seems to me that a good database will have that query cached in memory. It may sound "icky" but if you look at the times, I bet your Rails app spends way more time in the renderer than it does for the "select users.* from user" that it uses to populat current_user.

I'm happy to be proven wrong, but I've written a lot of apps before I moved to Rails, and we used to avoid re-authing the user / looking it up on each request, and it's just never made a bit of difference to us.

Re: Rails 3 Performance - Not Good Enough

#109

Post by ephramzerb »

cmelbye wrote: post #77
moe wrote: post #49

Earlier quoted context omitted.

culture of not giving a shit about performance Yes. On top of that the ruby ecosystem also seems to attract a certain class of programmers who simply don't know how their magic ruby code translates to CPU, I/O and memory operations. My pet example is a certain popular rails auth framework that hits the database for every single request, to look up tokens that could simply be baked into the cookie. But there are plent…

Out of curiosity, to which "popular rails auth framework" are you referring? Devise? Authlogic?

Clearance probably. It's really not a big deal with the index in place and it gives you more flexibility for revoking access to specific users without blowing out everyone's cookie. In practice, it's not a big deal performance wise. In a system where it would matter, you'd probably be past the point of an off-the-shelf gem being a good solve.

Re: Rails 3 Performance - Not Good Enough

#110

Post by joevandyk »

With 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.

Post reply on HN