Understanding Memory Usage in Rails Requests

Performance problems aren't always about speed.

Sometimes an application responds quickly but allocates far more memory than it should. Over time, those extra objects can increase garbage collection pressure, consume resources, and make an application feel slower than it ought to. While Rails gives us many ways to understand request timing, I've often found that understanding memory behavior is much harder. That challenge eventually led me to build RailsMemoryProfiler.

The Problem with Invisible Memory Usage

Most developers are comfortable tracking response times.

We know how to answer questions like:

• Why is this request slow?
• Which query took too long?
• Where is the bottleneck?

But memory is much harder to observe.

Questions such as:

• Which requests allocate the most objects?
• Why is garbage collection increasing?
• Which controllers are causing memory spikes?
• Has a recent change increased allocations?

are often much more difficult to answer.

Tools exist, but they typically require wrapping blocks manually or working entirely from the terminal.

Introducing RailsMemoryProfiler

RailsMemoryProfiler captures allocation information for requests and makes the results available through a built-in dashboard.

Instead of treating memory profiling as an occasional exercise, the goal is to make memory behavior visible during everyday development.

The gem provides insight into:

• Object allocations.
• Retained objects.
• Request duration.
• Controller activity.
• Allocation spikes.

The emphasis is on helping developers understand how memory usage changes over time without requiring complicated workflows.

Getting Started

Setup is intentionally simple.

Add the gem:

gem "rails_memory_profiler", group: :development

Run the installer:

rails generate rails_memory_profiler:install

Then mount the dashboard:

mount RailsMemoryProfiler::Engine, at: "/rails/memory"

Once enabled, requests are captured automatically and can be explored through the browser.

Bringing Memory Data Into Rails

One of the motivations behind the project was making memory information easier to browse.

Instead of scrolling through terminal output or manually running profiling sessions, developers can view request data in a dashboard designed specifically for Rails applications.

This makes memory profiling feel less like a specialized task and more like a normal part of development.

Catching Problems Earlier

Memory issues rarely announce themselves immediately.

Small increases in allocations can gradually lead to:

• Increased garbage collection.
• Higher memory consumption.
• Slower response times.
• More expensive infrastructure.

By making allocation data visible, RailsMemoryProfiler helps surface these trends earlier and makes it easier to understand the impact of changes.

Designed for Everyday Development

The goal wasn't to replace low-level profilers.

Instead, the goal was to provide something lightweight and approachable.

Features such as:

• Request sampling.
• Dashboard filtering.
• Notifications.
• Test helpers.
• Allocation thresholds.

allow developers to incorporate memory awareness into their existing workflow without adding significant complexity.

Why I Built It

I wanted something that answered a simple question:

How much memory is this request actually using?

Without requiring:

• Manual profiling sessions.
• Terminal-only tools.
• Complex setup.
• Specialized workflows.

I wanted memory usage to be as easy to inspect as response time.

RailsMemoryProfiler is the result.

Because performance isn't just about how long a request takes.

It's also about how much work the application does along the way.