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
Related
I'm trying to understand what exactly precompiling:assets does, because I've realized that for my last project my CSS would never update when I pushed my app to heroku unless I typed bundle exec rake assets:precompile, but this only started happening towards the end, so I believe I probably added something to the config file.
I'm currently trying to understand caching, which made me think about precompile:assets. Is precompile:assets similar to caching by pre-loading the assets to the web server so that those assets aren't loaded directly from the Rails stack? This is for performance purposes right?
Caching is a related, but separate topic.
The purpose of compiling assets includes the combining and minimizing of assets, e.g. javascript that is all on 1 line with 1 letter variables, as opposed to the originals which are used in development mode and let you debug there using the original source code.
You can find everything you need to know in the Asset Pipeline Rails Guide.
I'm working on a rails app where we want to allow the user to use an admin tool to create new themes. The admin tool is a separate application and communicates with our main application through a database. My problem is that I've written custom Sass extensions to load our data into our style sheets, but once that is done, I am unable to recompile the assets in our production environment.
So far I've seen two possibilities for this:
1.Increment the version of config.assets.version. So I have this code:
MyApp::Application.assets.version =
(MyApp::Application.config.assets.version.to_i + .1)
From what I've read incrementing this should cause the assets to recompile, but it seems to only work when it is incremented by hand and the server is restarted.
2.Create a compiler and tell it to clean up the old assets and recompile them:
compiler = Compass::Compiler.new(
Rails.root.to_s,
Compass.configuration.sass_path,
Compass.configuration.css_path,
{:sass => Compass.sass_engine_options} )
compiler.clean!
compiler.run
With this method, however, I run into the problem that the Sprockets::Index.expire_index! method raises an error when I try to create a new compiler.
Yes, I do understand that I can set the assets to recompile on every request, but the performance hit is not something we want. Also, since this is a theme, the data should not be changing often, so we only need to recompile when the admin chooses to save the new theme.
So, finally, my question is: Are there any other possible methods to do what I want? Or am I going down the right path, and if so, where am I going wrong?
EDIT:
I forgot to mention that since we are using Sass functions to change the values of the stylesheets, even if I do turn on the option to compile in production, it won't work. Since the actual stylesheets will never change.
Rails has a Rake task that does asset compilation for you. You should run it once every time you deploy your application to your production environment.
rake assets:precompile
The compiled assets are output to public/assets. For more details, check out the Rails Asset Pipeline Guide.
I have a Rails 3.2 app running on Heroku, and it uses CKEditor. Now, CKEditor is a pretty large collection of files and folders, and is probably the biggest contributor to the time it takes to precompile assets. A regular push to Heroku takes well over a minute on the assets:precompile step.
So I now precompile locally, and only when I've made edits, before I push to Heroku, to shorten deploy times. However, my poor old Windows laptop easily breaks 15 minutes for rake assets:precompile. This makes it a huge pain to make minor edits or additions to js or css files.
I do have config.assets.initialize_on_precompile = false as required by Heroku docs. But I'm pretty sure the real time hog is compression, i.e. Uglifier.
Does anyone have a suggestion to how I can remedy this? Am I simply doing it wrong? Is there a way to only compile changed files? Could/should I move CKEditor directly to the public dir to avoid precompiling?
You can try to load the assets only on the changed files which would speed up compiling process by a huge margin. You can easily do so using turbo-sprockets-gem.
https://github.com/ndbroadbent/turbo-sprockets-rails3
The documentation is pretty straight forward. Hope this helps.
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.
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