

Show HN: Rails Performance Help – Tracer Bullets - nate
http://ninjasandrobots.com/rails-performance-help-tracer-bullets/

======
sergiotapia
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](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.

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

~~~
nate
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.

~~~
cheald
I'm putting together a blog post. :)

That said,
[https://github.com/justinweiss/request_profiler](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.

------
gingerlime
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](https://github.com/gingerlime/measure-everything)

------
burgeralarm
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](https://github.com/bclune/rubber_bullets)

~~~
nate
I love the name! Thanks!

------
skram
Add
[http://railscasts.com/episodes/368-miniprofiler](http://railscasts.com/episodes/368-miniprofiler)
to your list of tools for development mode

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

~~~
nate
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.

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

~~~
jrochkind1
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?)

------
djbender
Very simple library and execution! Thanks so much!

~~~
nate
Of course, thank you for checking it out.

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

~~~
nate
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?

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

~~~
nate
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](http://www.artima.com/intv/tracer.html)

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

------
gkop
How is this better than New Relic?

~~~
nate
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.

