Rails Observer Causes Slow Processing Time in Design Mode

I'm on Rails 3.1.1, and I noticed that my application became extremely slow (15 seconds) in development mode. See my list of "Firebug Net" below:

Before!

I have done several things, such as:

  • gem reduction
  • turning class caching into
  • switching asset debugging to false
  • turning asset compression into true
  • rail installation-dev-boost gem

There might have been some improvements, but nothing helped him go as fast as I expected when running localhost. That is, until I commented out the configuration line of my observers in application.rb :

 config.active_record.observers = :item_observer, :loan_observer, :friendship_observer, :message_observer, :user_observer 

And then the application was fast again (~ 1 s) boot time. See now the firebug list:

After!

Other notes:

  • When in production at Heroku, it is fast (~ 1 s), as you would expect.
  • I use postgresql and thin; I have not tried using other databases to see if this problem exists.
  • When I commented only on the last observer, user_observer, the load time was reduced by about half.
  • The download time printed in development.log does not reflect the actual download time. Assets were marked as 304 Not Modified (0ms), which really took a while to load.
  • Yes, I use the asset pipeline

Golden Question: Is it a simple act of registering observers that force assets to load slowly? And what can be done about this?

+4
source share
2 answers

Take a look at https://github.com/wavii/rails-dev-tweaks .

Rails runs all the to_prepare hooks every time a Sprockets asset is requested in design mode. This includes things like automatically (re) loading your code, and various stones do the work there. And in your case, observers are logged in (which, I believe, makes Rails reference a good part of your application to reference models)

rails-dev-tweaks disables to_prepare and reloads any activation request (and several others - reads the first part of README). Speeds up its development environment by a huge amount for any decent size. It is also customizable for this for any additional queries you like.

+2
source

As I fix this, observer refactoring is causing problems. https://gist.github.com/1014971

0
source

Source: https://habr.com/ru/post/1379668/


All Articles