5 Essential Rails App Performance Optimization Tools

It’s just about the most frustrating thing in software development: You’ve built a clean app or a great site, but something is slowing it down. I’ve found that it’s not always obvious what’s killing my Rails app performance, so a lot of time can be wasted hunting down the culprit.

Here’s 5 essential Rails App Performance Optimization Tools that I’ve used to help investigate slow performance.

New Relic APM

You know New Relic. You’ve been there, you’ve done that, and now that you’ve got the T-shirt, you’ve also heard from their salespeople relentlessly. It turns out that in addition to an aggressive sales force, New Relic also offers a great tool for understanding your app performance.

New Relic APM gives you an Overview tab that shows you the overall app performance and throughput at a glance. You can check the Transactions (aka requests) and Database tabs to review requests and queries with a number of different sorting techniques. This way, you can identify the highest value performance improvements that you need.

New Relic offers a free service tier that still gives you access to a lot of great tools. This is a huge bonus over other proprietary tools. Also, they support a wide range of languages and platforms so you can use it on your non-Rails projects too. It’s laser-focused on helping you to quickly identify your highest-priority optimization targets. That’s why this is my favorite tool for identifying bottlenecks and understanding the impact they have on your users.

DataDog/datadog-rails

Datadog is another tool for collecting application metrics. This is a similar tool to New Relic. But Datadog allows for much deeper customization of which application data to collect and how to display it.

You can collect data on pretty much anything you can think of. Get resource usage for individual servers. Measure realtime response times. Get counts for rails requests (via datadog-rails). In addition to this, your retention period is much higher than what New Relic offers. This way, you can study changes in performance over weeks or even years.

More than likely you would choose DataDog or New Relic depending on your app’s or your engineers’ specific needs. It’s less focused than New Relic, and it does require a lot more cultivation to achieve that same level of focus. But it’s still an excellent tool for the right organizations.

Bullet

Bullet is a gem that can help you identify where you have N+1 queries or unused eager loading, or need counter caches in your ActiveRecord queries.

Of course, these are the easiest performance issues to tackle. So Bullet is a great first place to start when you’re trying to identify exactly what is making your requests slow. It’s very configurable. You can pipe warnings to the browser, server logs, and also external services like rollbar and airbrake.

Rack Mini Profiler

When Bullet isn’t giving you enough info and you’ve identified slow endpoints, rack-mini-profiler can step in and help with more information.

On each page load, rack-mini-profiler inserts an info overlay view. This is where you’ll see information about where the application spent time when processing your previous requests since the last in-browser page load. You can view how long it spent querying the database and how much time it spent rendering views. Rack-mini-profiler shows you the number of SQL queries that were executed in order to process the request. And, you can view each query with information about how long it took the DB server to execute it. This can help identify method-based N+1 queries that bullet doesn’t always find, as well as specifically slow queries (it highlights slow individual queries in red when viewing the list).

It also has flamegraph support when installed alongside the flamegraph gem.

StackProf

When all else fails, there’s also StackProf. StackProf is a sampling profile similar to rack-mini-profile but with a lot more tools and options for viewing the profile data.

You can use blocks to profile any chunk of code. StackProf works by sampling the call stack on an interval and using the sample data to determine which functions and methods spend the most time on the stack. Then, view this output as a text list based on time spent on each function. Or you can view it graphically as a flamegraph or directed call graph.

There are tons of options to mess around with in StackProf and I’ve only really scratched the surface of what’s possible, though the few things I touched on are very helpful on their own. Check out the readme for more tricks.

If you love creating great digital products, consider joining the Revelry team! Apply to work with us!

Check out our blog posts on development, product, and design

and leave a comment to let us know what you think. Keep in touch by subscribing to CODING CREATIVITY.

More Posts by Adam Clarke: