I'm on Rails 3.1.1 and I have noticed my app has become exceedingly slow (15 seconds) in development mode. See my firebug 'Net' listing below:
I've done a number of things like:
reducing the number of gems
turning class caching on
turning asset debugging to false
turning asset compression to true
installing the rails-dev-boost gem
Maybe there were some improvements, but nothing helped it to go as fast I'd expect when running off localhost. That is, until I commented out my observers config line in application.rb:
config.active_record.observers = :item_observer, :loan_observer, :friendship_observer, :message_observer, :user_observer
And then the app was fast again (~1 sec) load time. See the firebug listing now:
Other notes:
When in production on Heroku, it's fast (~1 sec), as you'd expect.
I'm using postgresql and Thin; I have not tried using other DBs to see if this problem exists.
When I commented out just the last observer, user_observer, the load time dropped by about half.
The load times printed in development.log do not reflect actual load times. Assets were flagged as 304 Not Modified (0ms) they really took a while to load.
Yes, I'm using the asset pipeline
The Golden Question: Is the simple act of registering observers causing assets to load slowly? And what can be done about it?
Take a look at https://github.com/wavii/rails-dev-tweaks.
Rails is running all of the to_prepare hooks on every Sprockets asset request in development mode. This includes things like auto-(re)loading your code, and various gems perform work in there too. And in your case, observers are being registered (which - I believe - causes Rails to reference a good portion of your app in order to reference the models)
rails-dev-tweaks disables to_prepare & reloading on any asset request (and a few others - read the first part of its README). Speeds up your dev environment by a huge amount for any decently sized project. It's also configurable to do this for any additional requests you like
The way I am fixing this is refactoring the observers into concerns. https://gist.github.com/1014971
Related
My app - cloudlist (cloudli.st) - uses Heroku, rails 3.2 and a bunch of gems. For the past few days we've started seeing our layout break a few hours after a deploy.
The strange thing is that the content of a file switches randomly on different requests. We use the rails asset pipeline with all defaults, nothing changed. Right after the deploy everything is fine. After some time (usually a couple of hours) the layouts starts to break in some areas. Sometimes just one image has a different content, sometimes even JS or CSS files have different content. We've also seen files that were completely mixed up. All this is very strange and I can't find anything on the web.
To illustrate the problem see the following image which have sprites with the wrong content.
Also see the content of the file frame.png. It should show the frame for a tile but sometimes it shows the awards nominee badge.
Has anyone seen anything similar or do you know how to solve this?
If this continues we need to migrate away from Heroku and use another infrastructure.
According to the recommendation given by heroku (https://devcenter.heroku.com/articles/rack-cache-memcached-rails31) here are the results.
In short: it didn't help.
Long version:
I don't use memcached for caching. Neither I use fragment or action caching. At least I don't use caching at all in my app.
The only thing that gets cached is stuff done by the configuration parameter
config.action_controller.perform_caching = false
in production environment.
I went through the article and checked every parameter. The only one I had different was config.serve_static_assets which was false. I set this to true, redeployed (with caching turned on) and got the same issues after a couple of hours.
I don't know what's wrong but as there is content in my files which doesn't match the expected I have to conclude that this is something within your infrastructure. E.g. I request application-(any-digest).css and I get sprite-(any-digest).png or application-(any-digest).js
Has anyone noticed an exponential difference in load times after upgrading to Rails 3.1. It's taking ~4 seconds to load a very basic request on my local development machine. Does anyone have any ideas how to solve this - suspect it's something to do with Rails new asset pipeline?
Take a look at https://github.com/wavii/rails-dev-tweaks.
Rails is running all of the to_prepare hooks on every Sprockets asset request in development mode. This includes things like auto-(re)loading your code, and various gems sneak work in there too.
rails-dev-tweaks disables to_prepare & reloading on any asset request (and a few others - read the first part of its README). Speeds up your dev environment by a huge amount for any decently sized project. It's also configurable to do this for any additional requests you like
If you're using Passenger, then one reason for the slowdown is that all assets are now served by the asset pipeline, instead of the webserver (Apache/nginx). The former is far slower than the latter.
Also, in development Rails usually handles requests one at a time, so if you have many images on the page the slowdown is very noticeable.
my idea would be (and i'd like to pack it into a gem, as soon as possible) to split up the development environment into frontend and backend development environments:
frontend:
- cache classes
- compile & serve assets on-the-fly
- use for javascript + css
backend:
- precompile assets (e.g. on server start)
- reload classes etc on every request
you can do this basically by adding a forth file to config/environments with the appropriate config statements, but you have to restart your server when you switch between frontend and backend work
My app is on Rails 3.0 so I can't speak to changes in the loading speed, however, I highly recommend using the rails-dev-boost gem. It significantly speeds up application load time in development, making it pretty close to Production speed.
Make sure you read the installation instructions since it's a bit different than simply adding gem 'rails-dev-boost to your Gemfile.
Since "upgrading" to Rails 3.1 my app is really slow in development mode
(> 30 per request)
I have a lot of images and it seems most of this time-delay is the asset pipeline processing each GET request for each image.
Don't have this problem in Staging or Production mode as the assets are cached etc.
Is there something I haven't been told or is this how we're expected to work now?
Requests can be slow if you have gems or portions of your app that load code at the start of each request - or that merely reference portions of your app, causing much of it to be loaded. For most of these, the autoloader is the prime cause of request delay.
The rails auto-reloader deletes any autoloadable classes/modules/etc at the start of each request, and can cause significant delays at the beginning of each request as Rails reloads all the source files it needs.
You might want to try playing with https://github.com/wavii/rails-dev-tweaks, which gives you granular control over which requests cause the auto-reloader to kick in. This really isn't a fix of the root cause (something is doing extra work at the start of every request that it probably doesn't need to be doing) - but it certainly mitigates most such issues.
In the meantime:
cp -R app/assets/images public/assets
really helps
remember to add public/assets/* to .gitignore
If your app is slow it is because of your app or one of the gems that you use. I had similar issue and it looks like Mongoid was the case more you can read here:
http://martinciu.com/2011/06/rails-3-1-and-slow-asset-pipeline.html
You can use a rake task:
rake assets:precompile RAILS_ENV=development RAILS_ASSETS_NONDIGEST=true
And as it was mentioned above, don't forget to include public/assets/* to .gitignore
Now that Rails 3 is out, my favorite dev-mode plugin (rails-dev-boost) is broken. I'm working on a large application (>100 models and controllers) and loading them all every request takes more than ten seconds. I could turn config.cache_classes on, but then I might as well run in production mode since I have to restart the server every change.
Is there something out there that could speed this up?
That plugin owner (rails-dev-boost) is working on getting it running with rails3, so hopefully soon!
I sure wish rails did that kind of stat-optimization out of the box!
https://github.com/thedarkone/rails-dev-boost
Here's the link to the rail3 branch (might disappear if/when the updates are moved into the core release)
https://github.com/thedarkone/rails-dev-boost/tree/rails3
At work, we have a situation where when
script/server
is run, then all the controller code is cached. This is to speed up the
development server. But that will mean that whenever we change the
controller code, we need to restart the server.
So we can turn off the caching of controller code all together. But
can't there be mechanism that is similar to the inclusion of javascript
foo.js?1275647624 <--- UNIX timestamp
which is to use the cached version as long as there is no code change,
but recompile it when there is code change?
Maybe because we use HAML and SASS a lot, loading some page (such as the
homepage of the site) can take 40 seconds on the dev environment and it
is quite long.
By default Rails will reload your classes for every request in the development environment. This should ensure that any changes are picked up. Classes are usually only cached when running in the production environment, or possibly if you have a staging environment set up.
Obviously I don't know your application, but 40 seconds to load a home page in development sounds like a long time. Are there any errors in the log?