ActiveAdmin is a commonly used tool for creating admin interfaces in Ruby on Rails applications. It's incredibly useful for quickly setting up an admin interface focused solely on the data you want to display. However, we often encounter pages that make numerous SQL requests and take a long time to load.
Today, we're going to look at three things I always do to optimize my ActiveAdmin views.
Table of Contents
Data Set Presentation
Introduction to ActiveAdmin
Filters
1️⃣ Always Use Custom Filters
2️⃣ Preload Your Own Collection and Cache It
Index
3️⃣ Preload Data in Your Controller
4️⃣ Preload Data in Your View
Results
Server-Side Rendering:
Rack-mini-profiler:
Conclusion
Data Set Presentation
To illustrate our examples, let's imagine that you need to integrate an admin interface for a temp agency.
You will have 4 tables:
- A table to store clients who pay to find temporary workers (Owner)
- A table to store all your available temporary workers (User)
- A table to store all the missions (Mission)
- A table to store all the mission shifts (MissionShift)
create_table "users" do |t|
t.string "email"
t.string "first_name"
t.string "last_name"
end
create_table "owner" do |t|
t.string "name"
end
create_table "missions" do |t|
t.string "description"
t.string "title"
t.bigint "client_id", null: false
end
create_table "mission_shifts" do |t|
t.bigint "mission_id", null: false
t.date "day"
t.datetime "begin_time"
t.datetime "end_time"
t.bigint "user_id"
end
The relationships are :
- A User have many MissionShifts.
- A MissionShift belongs to a Mission.
- A Mission belongs to an Owner.
That being explained, let’s dig into our use case !
Introduction to ActiveAdmin
Our goal is to use ActiveAdmin to create our admin interface as quickly as possible. You want a page that displays:
- The names of the missions
- The client to whom the mission belongs
- How many MissionShifts are staffed with a User
By reading a bit of the documentation, you discover ActiveAdmin's wonderful DSL.
You quickly come up with this code:
ActiveAdmin.register Mission do
index do
selectable_column
column :title
column :owner
column('Mission Shifts') do |mission|
mission_shifts = mission.mission_shifts
"#{mission_shifts.count(:user_id)}/#{mission_shifts.size}"
end
actions
end
end
Which results in this:
We have 148 SQL calls in the view 😲. That's huge!
Looking at the server side, here's the information we get when loading the page:
Completed 200 OK in 741ms (Views: 455.5ms | ActiveRecord: 266.5ms | Allocations: 1035126)
The page takes a lot of time to load and allocates a huge amount of memory!
The purpose of this article is to show you how to significantly reduce these SQL calls and memory allocation, thereby optimizing the time it takes for the page to render and reducing memory leaks!
Filters
1️⃣ Always Use Custom Filters
The first tip I'd like to share today is well-known. It doesn't solve our N+1 issue, but it greatly reduces the memory allocated by the page:
Never leave the default filters on!
In fact, ActiveAdmin tries to be helpful and generates filters for all attributes of your table.
- If you have many attributes, it's hard to navigate.
- If you have relationships with other models, ActiveAdmin will preload the entire ActiveRecord collection. In our case, we have the
OwnerandMissionShiftmodels included by default.
Always specify at least one filter:
ActiveAdmin.register Mission do
filter :title
[...]
end
Here's the server-side rendering when I load the page:
- Before the modification:
Completed 200 OK in 620ms (Views: 422.9ms | ActiveRecord: 186.0ms | Allocations: 928758)
- After the modification:
Completed 200 OK in 581ms (Views: 403.4ms | ActiveRecord: 168.0ms | Allocations: 703878)
There's a huge difference in memory allocation!
2️⃣ Preload Your Own Collection and Cache It
If you still want a filter for a Model, write your own query to load the data:
ActiveAdmin.register Mission do
filter :owner, as: :select, collection: lambda {
Owner.pluck(:name, :id)
}
[...]
end
Here's the server-side rendering when I load the page:
Completed 200 OK in 666ms (Views: 337.9ms | ActiveRecord: 316.7ms | Allocations: 761030)
It's still better than with the default filters.
If you want to go even further in optimization, you can also set up a caching logic like this:
ActiveAdmin.register Mission do
filter :owner, as: :select, collection: lambda {
Rails.cache.fetch('owners_name_id', expires_in: 1.hour) do
Owner.pluck(:name, :id)
end
}
[...]
end
This gives us:
Completed 200 OK in 816ms (Views: 531.6ms | ActiveRecord: 248.3ms | Allocations: 711373)
In terms of allocation, we've come a long way!
Index
On our index page, we have two problems:
- Displaying the
Ownercolumn - Displaying the number of MissionShifts that have a User per Mission
To summarize how ActiveAdmin works, for each line, it makes 3 SQL queries:
- One to find the Owner
- One to find the MissionShifts
- One to count the MissionShifts that have a User
As you can see, all our N+1s are actually concentrated here.
The only way to solve our issues is by preloading as much data as possible. For this, we have two ways:
- Preload the data in the controller
- Load the data once and memoize it in the view
3️⃣ Preload Data in Your Controller
ActiveAdmin allows us to create our own controller methods. So far, we have only played with the #index method, so if we want to preload data, this is the place!
Let's modify our file to preload the Owner data directly from the controller:
ActiveAdmin.register Mission do
[...]
index do
[...]
column('Owner') do |mission|
owners.fetch(mission.owner_id)
end
[...]
end
controller do
# before loading anything, we preload Owners
def index
@owners = Owner.pluck(:id, :name).to_h
# call for the initial index method
super
end
end
end
If we look at the rack-mini-profiler, we get this:
We have eliminated almost 100 database calls by preloading the data for Owners and MissionShifts.
Results
Here are the results with all the tips applied:
Server-Side Rendering:
- Before:
Completed 200 OK in 741ms (Views: 455.5ms | ActiveRecord: 266.5ms | Allocations: 1035126)
- After:
Completed 200 OK in 200ms (Views: 187.3ms | ActiveRecord: 5.9ms | Allocations: 517789)
Memory allocation was halved.
The response time is around 200ms (which is acceptable).
Rack-mini-profiler:
- Before:
The numbers speak for themselves, only 6 SQL queries compared to 148 before. It's a huge gap for the performance of your applications.
The important indicator to look at is the % in sql, which we reduced from 15.6% to 3.5%, a huge difference!
Conclusion
In conclusion, this article demonstrated how to transform an initially heavy and inefficient ActiveAdmin interface into a significantly more effective and faster version. Thanks to four simple yet powerful tricks, we drastically reduced SQL queries, improved memory management, and optimized loading time. These improvements are not just technical gains; they translate into a smoother and more professional user experience. For Ruby on Rails developers using ActiveAdmin, these methods offer a concrete way to enhance the performance of their applications while maintaining the ease and speed of development that this gem offers.
SOCIAL SHARE CARD GENERATOR