“Rails is slow.”

It’s a phrase many developers hear throughout their careers. However, Rails isn’t inherently slow; it becomes slow when we make expensive mistakes in our code and lack the visibility to find them. This guide breaks down a top-down approach to monitoring and fixing performance issues to ensure your application scales effectively.

1. The Power of APM (Application Performance Monitoring)

To fix performance, you first need data. APM tools like New Relic, Datadog, or Scout APM provide vital “telemetry” data to monitor the health of your app.

Key Metrics to Watch:

Request Queuing: This measures how long a request waits before being processed by your server. Ideally, this should be between 20ms and 50ms. If it’s higher, your servers are overloaded; if it’s consistently lower, you might be over-paying for hardware.

Top Transactions: Don’t guess what’s slow. Look at your most frequent and slowest endpoints to identify which areas of your code will provide the biggest performance gain when fixed.

Object Allocation: High memory usage is often caused by creating too many Ruby objects. For example, using Product.all on a large database will spike memory. Instead, use find_each to load records in small batches.

2. Profiling and Benchmarking

Once you know which page is slow, you need to find the specific line of code responsible.

Profiling: Tools like rack-mini-profiler allow you to see exactly how much time is spent on SQL queries vs. rendering directly in your browser. It provides a “backtrace” so you can link a slow query to the exact file and line in your Rails app.

Benchmarking: If you think a code change will make things faster, you must prove it. Using tools like Benchmark IPS (Iterations Per Second) allows you to compare the “Before” and “After” of your changes with statistical accuracy.

3. Common Performance Killers

Most Rails bottlenecks fall into a few predictable categories. Avoid these common mistakes:

I. Advanced N+1 Queries

We often miss N+1 queries in complex views. Watch out for: The Count Trap: Using .count on an association triggers a database query every time. Use .size to use the data already in memory. The Filter Trap: Using .where on an eager-loaded association forces a new database hit. Use Ruby’s .find or .select to filter the data in memory instead.

II. Synchronous External Tasks

Never make a user wait while your app talks to a third party. Tasks like sending an email, an SMS, or a WhatsApp message should always be moved to a Background Job. This keeps the user experience snappy and the server free to handle the next request.

III. Third-Party Timeouts

If you rely on an external API, never use the default timeout (which is often 60 seconds). If that service slows down, your entire app will hang. Set strict timeouts—usually around 2 seconds—to fail fast and stay in control of your app’s responsiveness.

IV. Missing Database Indexes

A missing index forces the database to scan every single row in a table (a Sequential Scan). Adding a simple index can reduce query costs from thousands to nearly zero. Use the EXPLAIN command to see how the database plans to run your query and identify where indexes are missing.

Summary

Scaling Rails is about a disciplined, top-down approach:

  1. Monitor with APM to find the bottleneck.
  2. Profile to find the specific line of code.
  3. Benchmark to prove your fix works.
  4. Optimize by fixing N+1s, moving tasks to background jobs, and adding database indexes.

By following these steps, you can ensure your Rails application stays fast, regardless of how much traffic you receive.