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.
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 would like to reload production application running with Thin. I know there is development mode, but our app is so complicated it simply cannot run in the development mode (it is very slow and unusable as we are more-or-less enterprise integration app). And we are not able to upgrade to Rails 3.2 which improved development mode.
Is there any way of reloading configuration with Thin or do I need to restart everytime? If not, I will keep restarting everytime I need to change something on a production setup in our testing environment.
In your config/environments/production.rb file you could turn the caching settings to false in order to have it behave more like development. This will allow you to update models etc.. without needing to restart the server. You won't want to check that into source control though. This may negate your entire reason for using production environment to speed things up though.
For reloading environment or initializer configurations you must always restart the server whether in development mode or not.
I personally would just be running the development environment as thats the intent. I've work on a couple large enterprise apps, and not had development environment unable to run...
If performance is the issue there are a couple things you could try to speed things up:
1) try using active_reload which was the precursor for much of the Rails 3.2 performance improvements https://github.com/paneq/active_reload
2) you can look into precompiling your development assets if its the asset pipeline slowing things down
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
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?
I just look up at rails sources and find folder named "dispatches". There is four file in it. I want to know purpose of this files. I know I use this files on my production server, but I never used to think of their purpose. I know there is something about attaching Rails app to Apache server. On my production server rails appname command add this files to public folder automatically. Can I set up this behavior on my development machine?
The rails dispatcher is the entry point for a rails application and is used to bootstrap the environment.
They have a long history and in a lot of ways they are almost obsolete. In days gone by rails apps used to be powered using cgi or fastcgi, which was a way for the webserver to communicate with a rails process. The boot process would be initiated by dispatch.fcgi or dispatch.cgi. Nowadays people are more likely to use apache/nginx+passenger or apache/nginx+mongrel/thin. (Does anyone still use lighttpd?)
I'm a little fuzzy on how dispatch.rb is used, but I think it's used by upstream rails servers such as mongrel/thin to bootstrap the rails process. However, now that rails is rack compatible I'm not entirely sure if that has changed.
You don't need to pay the dispatch.* files any attention.
I hope this helps.