I'm running a rails 3.1 app on Heroku Cedar stack which supports the asset pipeline. Heroku lists 3 ways to compile assets
Obviously #3 is bad for performance and Heroku docs also recommend against it. But I'm not sure which is better between #1 and #2.
#1 requires that you run rake assets:precompile
and include your public/assets
folder in git. Your slug will be bigger but I assume the downtime for deploying a site will be lower. But bigger slug size means slower app startup so maybe it's a wash.
#2 will make it take longer to deploy updates because of precompile being done on Heroku side. However, you will have a smaller slug and there's less to manage/remember.
My question is - which option (#1 or #2) is the best for production and why?
So far it looks like option #2 but I want to make sure I'm not overlooking something.
To compile your assets locally, run the assets:precompile task locally on your app. Make sure to use the production environment so that the production version of your assets are generated. A public/assets directory will be created. Inside this directory you'll find a manifest.
rake assets:clean Only removes old assets (keeps the most recent 3 copies) from public/assets . Useful when doing rolling deploys that may still be serving old assets while the new ones are being compiled.
Slugs are compressed and pre-packaged copies of your application optimized for distribution to the dyno manager. When you git push to Heroku, your code is received by the slug compiler which transforms your repository into a slug. Scaling an application then downloads and expands the slug to a dyno for execution.
I addressed some of these issues and a big gotcha in my question here: Rails 3.1.1 asset pipeline Heroku caching gotcha
I'd prefer #2 if it worked for me so I don't have to checkin compiled assets which just bloats the git repository.
Compiling assets during slug compilation won't result in any additional downtime because your existing app will stay up until slug compilation is complete so no worries there.
My advice would be #2 if you can make it work for you. If you do end up going w/ #1 then take best practice would be to git rm -r public/assets before rake assets:precompile to make sure no cruft remains.
It could depend on the size of your asset folder, (and maybe a long term solution would be to put those assets outside the application and host them on S3 or the like.)
Otherwise, I am supposing #1 would be the best on production since any asset can be used and cached straight away.
I am reading Heroku's documentation section on assets, and they seem to indicate that #2 would be used just in case you have forgotten to do it yourself, as a convenience. You will not get a small slug, since the results of asset preparation will be included in the slug to deploy itself.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With