Active admin slowing down rails application

Question

I installed the active_admin gem in a working rails application. After doing this, the app noticeably slowed down. It takes around 4-5 seconds to get a new page. Some functionality is broken.

Is this possibly due to active admin relying on devise and conflicts arising because I have my own authentication? I already had a User model with methods like 'current_user' and sign in features.

In other words, are you not supposed to use active admin unless using devise for authentication? I don't see anything about this in the documentation.

I'm on Rails 3.1, Postgresql database, if that matters.

Answer 1

The slow down in Rails 3.1 is a known issue that is mostly due to the the way Active Admin interacts with the new Asset Pipeline. The issue is - as far as I'm aware - only present when running in development mode (so when you deploy to production it should go away).

There is also a memory leak issue in development that might have a performance impact. But my personal experience is that this isn't the main performance killer.

To overcome the slow environment issue in development, one quick fix is to install the rails-dev-tweaks gem. This will prevent Rails from regenerating assets when the incoming request is an asset request (images, css, js etc.).

As to your second question: Active Admin only works with devise. But it is entirely possible to use a different authentication mechanism in your frontend and only rely on Devise in Active Admin. You should of cause ensure that Devise and your own authentication does not conflict. You can change devise and Active Admin to use a different method for retrieving the current user. By default Active Admin uses current_admin_user - not current_user. You can change the authentication settings for Active Admin in config/initializers/active_admin.rb. For more info, read the authentication documentation.

Answer 2

If your admin models have belongs_to and has_many relationships and the default behavior of ActiveAdmin will practically load your database into RAM. It is recommended that you add only the filters truly needed.

Specifying the exact fields for each filter collection will also greatly reduce query execution time and memory footprint. By default, ActiveAdmin is looking for :id and :name attributes. One query I applied this to reduced from several seconds to .7ms. YES!!

e.g.

filter :account, collection: Account.unscoped.select(‘id, name’)