Show HN: Rails Performance Help – Tracer Bullets | Hacker News Reader

Show HN: Rails Performance Help – Tracer Bullets

ninjasandrobots.com

68 pointsnate22 comments

Also if you want something to pull your ear when you're fudging things up, use the Bullet gem.

Literally, just add this initializer in your development.rb

    config.after_initialize do
      Bullet.enable = true
      Bullet.alert = true
      Bullet.bullet_logger = true
      Bullet.console = true
      Bullet.growl = true
      Bullet.xmpp = { :account  => 'bullets_account@jabber.org',
                      :password => 'bullets_password_for_jabber',
                      :receiver => 'your_account@jabber.org',
                      :show_online_status => true }
      Bullet.rails_logger = true
      Bullet.airbrake = true
    end

https://github.com/flyerhzm/bullet

>The Bullet gem is designed to help you increase your application's performance by reducing the number of queries it makes. It will watch your queries while you develop your application and notify you when you should add eager loading (N+1 queries), when you're using eager loading that isn't necessary and when you should use counter cache.

Why not just go straight for ruby-prof? You can use it to instrument discrete sections of code or whole programs, and you can dump the results to things like cachegrind format, making comprehensive performance analysis of your code extremely easy.

That's a good question. I've used ruby-prof before, but for me that requires a cognitive load and steps I don't always want to preform in many situations. This just seems simpler. Install gem, sprinkle tb's in my code, and oh there is that dumb block of code I hacked together that doesn't perform very well.

I'm putting together a blog post. :)

That said, https://github.com/justinweiss/request_profiler is as simple as a Gemfile line and request parameter, and gives you far deeper introspection of your code.

The blog post, as promised:

http://coffeepowered.net/2013/08/02/ruby-prof-for-rails/

Shameless plug, but I just gave a talk yesterday[1] at the Rails User Group Berlin meetup that covers some techniques + gems for measuring stuff, including execution time. Primarily using Statsd/Graphite, but not exclusively. These can be useful even in production, because of the low overhead.

Rails instrumentation in particular allows plugging into controller actions, and things like the nunes gem hooks in even more places. But of course, you can also track timing info around blocks or methods quite easily on a ad-hoc basis.

Lots of this you get 'out-of-the-box' with newrelic (/pro), but this gives you even more flexibility and control.

[1] https://github.com/gingerlime/measure-everything

This is pretty cool. Simple but extremely useful.

I've written a quick and dirty port to Python, for anyone who'd like to take a look:

https://github.com/bclune/rubber_bullets

I love the name! Thanks!

Add http://railscasts.com/episodes/368-miniprofiler to your list of tools for development mode

Nice, I've often needed this as an initial look at where the slowpoints might be, and hacked my own solution, this will be helpful.

Awesome to hear! The version I used at the Obama campaign had other bells and whistles like color coding the log entry. I just arbitrarily picked some time I thought was slow, made it read, less slow, made it yellow, others green. That might be a nice addition still.

I've found timestamping Rails.logger output helps considerably, and offers a similar - yet more generic - insight.

It is a mystery to me why Rails.logger _takes away_ the timestamping that default stdlib Logger adds by default usually -- and further than this, makes it harder to customize the Rails Logger output than it should be (or has Rails finally fixed that?)

Very simple library and execution! Thanks so much!

Of course, thank you for checking it out.

I've done very similar things at various times to identify performance problems. Except I would track the start time so I could calculate the elapsed time for each section and record a label for it. Then I grep the logs and see which sections were slow and compare different runs with each other.

Thanks for the comment. I might not understand though yet. Tracer bullets does track the elapsed time in between each section. Are you saying it's more useful sometimes to track a cumulative total of the elapsed time for each of these lines?

Isn't the tracer bullet analogy from either code complete or the pragmatic programmer?

Dave Thomas and Pragmatic also have a tracer bullet analogy. But in that case it's more about "prototype" code being used as a tracer bullet instead of requirements and specifications to figure out what people want.

http://www.artima.com/intv/tracer.html

it's funny that something like this existed in CFML for a while now (CFTRACE), yet CFML is looked down upon. its cool though to see this functionality in another programming language.

How is this better than New Relic?

Thanks for the question! Well, production web transaction traces in New Relic are only available to paying customers - and pay you will :).

But also those usually only give you great data about SQL statements or things like this (Application code (in Document#transaction)) which doesn't say much, unless you add more New Relic instrumentation blocks in your code, which then requires a re-deploy.

Also, New Relic dev mode hasn't been updated in a long long time the last time I checked, and it was really buggy in showing you what line of code you were in.

Reply on news.ycombinator.com