cfis : Making Rails Go Vroom

Comment on Making Rails Go Vroom by Paul

Wed, 18 Jul 2007 14:20:08 -0600

Great write up. Nice to see that there is a lot of room for speeding things up with a bit of work.

Of course everyone’s app will be different but some key bits of info everyone can apply.

Trackback from MapBuzz Blog: Performance Improvments on Making Rails Go Vroom

Wed, 18 Jul 2007 14:28:26 -0600

Last week we spent a a day combing over MapBuzz's map rendering performance. With just a bit of work, we were able to improve it over 700 percent! If you're interested in the details, I wrote a full post about it on my personal blog.

Comment on Making Rails Go Vroom by tom

Wed, 18 Jul 2007 14:54:31 -0600

Hmm… seems like Rails optimizations often boil down to removing syntactical sugar and bringing things out of the cozy Rails nest.

Comment on Making Rails Go Vroom by Nick Kallen

Wed, 18 Jul 2007 14:59:23 -0600

Using include can vastly slow things down depending on the context. The problem is Rails has to generate these very sophisticated queries–the t0_c0 stuff–and extract that data out into the different models. I’ve done lots of profiling on :include and these numbers are misleading. It really depends on context.

Comment on Making Rails Go Vroom by Charlie

Wed, 18 Jul 2007 15:16:56 -0600

Hey Nic,

Thanks for the comment. I’d like to hear more about your findings with :include. I’ve haven’t seen them slow down our application, but I’m sure they are cases where it could happen.

But are you sure the slowdown really comes from generating queries? That code is conceptually simple and its implementation isn’t that complex (I had to dive through it for the select parse plugin).

It seems more likely to me that the slowdown you see would happen either because 1) the query gets complex enough that database performance suffers or 2) parsing of the results gets complicated enough it slows down the query.

Or is this not what you saw?

Comment on Making Rails Go Vroom by Charlie

Wed, 18 Jul 2007 15:20:00 -0600

Hi Paul,

I definitely agree that everyone’s application is different - what we see is most likely not same thing that others see. So grab a copy of ruby-prof and find out for sure (or DTrace if on Solaris).

Charlie

Comment on Making Rails Go Vroom by Charlie

Wed, 18 Jul 2007 15:23:00 -0600

Hey Tom,

Suppose it depends on what you mean by syntactical sugar. Is url_for syntactical sugar? I’d say no - its more a Rails API. So its more about knowing which apis to avoid - or as you say, getting out of the cozy Rails nest when necessary.

Comment on Making Rails Go Vroom by Michael Koziarski

Wed, 18 Jul 2007 15:34:59 -0600

If you’re interested in helping out with an improved implementation of Active Record’s attributes, you should drop us a line on the rails core list.

Some of those issues, especially the repeated-parsing of dates etc, would be nice to fix for 2.0.

As for url_for, how were you using it? Named routes or hash arguments?

Comment on Making Rails Go Vroom by Charlie

Wed, 18 Jul 2007 15:59:43 -0600

Hey Michael - I’ve been meaning to write up my thoughts on ActiveRecord and attributes for a while now….

I’ll definitely drop a line to the core list when I do - hopefully they’ll add some value.

As far as routes, we just use 5 regular routes, not named routes. I can post them if you’d like - but its pretty simple stuff.

Comment on Making Rails Go Vroom by Michael Koziarski

Wed, 18 Jul 2007 17:00:38 -0600

Optimising regular old routes will be challenging, however I do think that there’s the possibility of significantly increasing the speed of named routes. After all, they don’t have to search to find the possible matches, there’s only one. So each of the foo_url() methods could instead just be a string mashing method like you use above.

We’re definitely interested in hearing any thoughts from people who’ve taken the time to profile their applications and have some ideas / patches to speed things up.

Comment on Making Rails Go Vroom by Michele

Wed, 18 Jul 2007 17:32:16 -0600

Great tips! We’ll definitely look into this in the future. Thanks for sharing… :)

Comment on Making Rails Go Vroom by Chris

Wed, 18 Jul 2007 20:51:36 -0600

Excellent tips here … bookmarked your site and look forward to more brain-pickin’! :D

Trackback from hervalicio.us/blog: Making Rails go Vrooom on Making Rails Go Vroom

Thu, 19 Jul 2007 06:45:02 -0600

An awesome article pointing out a big bunch of performance improvement tips for Rails applications that brought down rendering time up to 700% on Charlie’s application. Quite an improvement indeed! The tip on not using link_to and url_for is...

Comment on Making Rails Go Vroom by Jim Cropcho

Thu, 19 Jul 2007 13:03:26 -0600

Great post!

In regards to your “Don’t Use ActiveRecord:attributes” section:

Would it be useful to redefine ActiveRecord’s attr_reader method, i.e.:

def attr_reader(attrib) read_attribute_before_type_cast attrib end

so that the changes are made across the application for accessor methods, or does this not optimize like your example?

Comment on Making Rails Go Vroom by Jim Cropcho

Thu, 19 Jul 2007 13:07:14 -0600

Great post!

In regards to your “Don’t Use ActiveRecord:attributes” section:

Would it be useful to redefine ActiveRecord’s attr_reader method, i.e.:

def attr_reader(attrib)

read_attribute_before_typecast attrib

end

so that the changes are made across the application for accessor methods, or does this not optimize like your example?

Comment on Making Rails Go Vroom by Charlie

Thu, 19 Jul 2007 14:14:46 -0600

Hi Jim,

I think its probably not a good idea to redefine attr_reader since its highly likely that it will break your application. Also, you would have to do the typecasting yourself.

I haven’t looked at Rail’s autogenerated methods for a while, but its possible they cache the values anyway. In our case, we were directly accessing attributes in a couple places, and that turned out to be too slow.

Comment on Making Rails Go Vroom by Senthil Nayagam

Fri, 20 Jul 2007 06:32:32 -0600

nice article.

we did some of our optimisations lately for our very complex app. and were able to reduce queries by 90%.

hope you would agree, optimisation is left for the end phase. when you really need them for performance.

the syntactic sugar is what makes us do the crazy ideas come to life faster.

will test your finding myself and report the gains.

Senthil

Comment on Making Rails Go Vroom by Charlie

Fri, 20 Jul 2007 11:00:53 -0600

Hi Senthil,

As the old adage goes - “don’t prematurely optmize.” I have to say I’m of two minds about that. On the one had, spending a lot of time upfront doing micro-optimizations like the ones I write about are a waste of time. On the other hand, if your architecture cannot support the performance you need, and you don’t discover that until the very end, then you are screwed.

Looking forwarding to hearing your results - accurate, published performance information helps us all!

Comment on Making Rails Go Vroom by topfunky

Fri, 20 Jul 2007 12:11:32 -0600

The most important thing in this article that is also the most easily missed is BENCHMARKING!

Don’t blindly apply any of the techniques here until you have profiled or benchmarked your application to see what the bottleneck is. The ruby-prof plugin is awesome for this purpose.

Applying the techniques mentioned here only gave me a 5% speed boost, but using the ruby-prof plugin helped identify and fix a separate bottleneck that gave me a 200% speed boost. If I didn’t use ruby-prof, I would never have found that other bottleneck.

Comment on Making Rails Go Vroom by Charlie

Fri, 20 Jul 2007 12:54:36 -0600

Hi Topfunky,

Absolutely. We focused on this particular request because our log files showed it was dreadfully slow.

ruby-prof is the last step in any performance improvement project. First you have to find out what requests are slow (use your log files). Second, you have to figure out why they are slow (is it processing the request, rendering the results, querying the database, etc.). And finally, if you’re sure the problem is in your Rails code (or Rails), then break out ruby-prof to see what it is.

I’m not surprised you only gained 5% from doing the same things we did. Our use case was a bit unusual - lots of partials with lots of URIs with lots of datetimes.

Curious how you gained your 200%. Any lessons for the rest of us?

Trackback from blogwi.se: How-to Profile your Ruby (on Rails) Application on Making Rails Go Vroom

Sun, 22 Jul 2007 11:26:29 -0600

Our current project is by far not yet in the state where we can and want to profile it’s overall performance, but considering its current pace, we might be there in a couple weeks and therefore this post also is meant to be a little reminde...

Comment on Making Rails Go Vroom by Binal

Mon, 23 Jul 2007 02:31:18 -0600

Hey, your post helped me in identifying the show stoppers and optimizing my rails app too :-)

Comment on Making Rails Go Vroom by thies

Thu, 26 Jul 2007 04:03:56 -0600

hmm, just a quick hack - rails uses Date._parse to parse the strings returned from the database in my case (MySQL) the strings are either of format YYYY-MM-DD or YYYY-MM-DD HH:II:SS

so i wrote this tiny patch to the Date class which takes care of all the common cases without haveing to touch my models:

class Date class << self

alias :_slow_parse :_parse

def _parse(string, comp=false)
  if string =~ /^(\d+)-(\d+)-(\d+)$/
    return {:year=>$1.to_i, :mon=>$2.to_i, :mday=>$3.to_i }
  elsif string =~ /^(\d+)-(\d+)-(\d+) (\d+):(\d+):(\d+)$/
    return {:year=>$1.to_i, :mon=>$2.to_i, 
            :mday=>$3.to_i, :hour=>$4.to_i, 
            :min=>$5.to_i, :sec=>$6.to_i }
  else
    a = _slow_parse(string, comp)
    puts "Date::_parse slow #{string} -> #{a.inspect}"
    return a
  end
end

end

what do you think?

thies

Comment on Making Rails Go Vroom by Charlie

Thu, 26 Jul 2007 10:25:42 -0600

Binal - Find anything worth sharing with others?

Comment on Making Rails Go Vroom by Charlie

Thu, 26 Jul 2007 10:28:00 -0600

Hi Thies,

Yeah - using regexs is the approach that the Time class takes, so that looks good to me. Maybe you can reuse it directly, or are your date formats slightly different?

As far as overriding _parse, I think that’s the right solution if you have a lot of dates. Having to add custom attributes each time would be a pain. In our case, we only have 2 of them, so it wasn’t a big deal.

Trackback from Quicklinks: links for 2007-07-27 on Making Rails Go Vroom

Fri, 27 Jul 2007 05:17:14 -0600

How to Profile Your Rails Application (tags: Rails performance development) Making Rails Go Vroom (tags: Rails development performance)...

Trackback from Ideas at Work: The Definitive and Abbreviated Guide to Rails Performance on Making Rails Go Vroom

Sun, 29 Jul 2007 18:35:41 -0600

Charlie Savage has released a major update to ruby-prof a "a superfast, open-source, profiler for Ruby", with new support for Rails projects. In what is likely to become the definitive and abbreviated guide to Rails performance, he has written a p...

Trackback from Scott's Place: links for 2007-07-31 on Making Rails Go Vroom

Mon, 30 Jul 2007 18:21:45 -0600

Making Rails go Vroom Practical walkthrough of optimising a Rails app using profiling reports (tags: activerecord articles code deployment dev development geek howto optimisation performance rails reference ruby rubyonrails software speed tips tut...

Comment on Making Rails Go Vroom by rick

Tue, 31 Jul 2007 21:18:32 -0600

I don’t think read_attribute actually calls #attribute as you claim, it pulls the value from @attributes like #read_attribute_before_type_cast. The generated methods don’t cache the type casted attributes though, so multiple calls to #created_at would call the slow Column#string_to_time method each time.

Comment on Making Rails Go Vroom by Charlie

Wed, 01 Aug 2007 23:25:08 -0600

Hi Rick,

I double checked, and you are right. read_attribute does do the type cast (from string to whatever) but you generally want that. Thanks for the correction and I’ll update the blog.

Comment on Making Rails Go Vroom by Bob Hutchison

Fri, 03 Aug 2007 05:50:29 -0600

Nice article… it prompted me to check my own code out, and work out how to get the plugin to work with old versions of Rails. Post is here: http://recursive.ca/hutch/2007/08/03/398/ if anyone is interested.

Comment on Making Rails Go Vroom by Charlie

Fri, 03 Aug 2007 14:11:17 -0600

Hi Bob,

Thanks for the link. Good point on the old versions of rails. Suppose the plugin could just use alias. Or maybe define alias_chain if needed.

If you have the time, could you add patch to the ruby-prof project on ruby-forge and I’ll include it in the next release?

Trackback from Web App: Juvely: We’ve moved on Making Rails Go Vroom

Fri, 28 Mar 2008 05:56:48 -0600

This time last week I planned on testing a new server. Now we are running on that new server! As I said in my post then I was thinking of going with SliceHost, well (sorry guys), but in the end we decided to go with Linode. Everything has been mig...

Comment on Making Rails Go Vroom by Hardy

Tue, 01 Apr 2008 04:53:01 -0600

Good, Keep it up.. to optimizing more… Interesting topic it is.