Hello all,
For me, assets precompilation is really boring, slow and even complicated as additional configuration is necessary.
That is why I’ve made a live asset compilation so that on the first request the assets get compiled and put on the static asset path (public/assets), just like rake assets:precompile do, so that on the next request it is going to be served by Nginx.
Please comment on the idea. GEM source code at https://github.com/coletivoEITA/assets_live_compile
cheers,
bráulio
The reason for asset precompilation in production environments isn’t just caching and speed on the first request, it’s also that you don’t want to have to have a JS environment (e.g. TheRubyRacer) in production.
And another reason for pre-compilation is that it can happen on district asset host boxes or even be pushed to a CDN which the apps use for an asset host.
pushed to a CDN which the apps use for an asset host
I recommend not doing this. You can set up your CDN to “pull” instead which is much more sane and less error prone: https://devcenter.heroku.com/articles/using-amazon-cloudfront-cdn. Source: hundreds of Heroku support tickets.
assets precompilation is really boring, slow and even complicated
Agreed, however your solution only moves the slow, complicated, boringness to the realm of your users; it doesn’t get rid of them. Now instead of you having to wait for your assets to precompile before an app is deployed, your users have to wait for assets to be compiled the first time they hit a page. If you think 30 seconds is a long time to wait for compilation on push, how do you think a user will feel about a 30 second long request to your homepage?
pushed to a CDN which the apps use for an asset host
I recommend not doing this. You can set up your CDN to “pull” instead which is much more sane and less error prone: https://devcenter.heroku.com/articles/using-amazon-cloudfront-cdn. Source: hundreds of Heroku support tickets.
assets precompilation is really boring, slow and even complicated
Agreed, however your solution only moves the slow, complicated, boringness to the realm of your users; it doesn’t get rid of them. Now instead of you having to wait for your assets to precompile before an app is deployed, your users have to wait for assets to be compiled the first time they hit a page. If you think 30 seconds is a long time to wait for compilation on push, how do you think a user will feel about a 30 second long request to your homepage?
It’s interesting that you mention that. In development mode (with debug assets off) the consolidated assets build and serve in milliseconds. I’m still unsure as to why the asset pre-compile takes so long.
Likely because you do not have an asset/sprockets cache configured. http://blog.alexmaccaw.com/faster-deploys
Hello Richard,
We fix that by making a warm up request just after the server load. See https://gist.github.com/brauliobo/11298486
cheers,
bráulio
BTW, new Rack support warm up.
Hello Ken,
This is not good enough as the rails server is going to be reached for each asset request. You want nginx or another server to serve assets.
cheers,
bráulio
Serving in milliseconds
This is because sprockets doesn’t generate hashes, remove whitespace, compress javascript, or compile all JS to one file.
If you don’t need any of those things then don’t use the asset pipeline, store your assets in /public and serve them individually.
Likely because you do not have an asset/sprockets cache configured.
If you are deploying to Heroku
DO NOT USE http://blog.alexmaccaw.com/faster-deploys on Rails 3 DO NOT USE http://blog.alexmaccaw.com/faster-deploys on Rails 3
DO NOT USE http://blog.alexmaccaw.com/faster-deploys on Rails 3 DO NOT USE http://blog.alexmaccaw.com/faster-deploys on Rails 3
DO NOT USE http://blog.alexmaccaw.com/faster-deploys on Rails 3
For the love of god and all that is holy. It will break your application, maybe not today, maybe not tomorrow, but eventually. If you missed it:
DO NOT USE http://blog.alexmaccaw.com/faster-deploys on Rails 3
This is because Rails 3 has issues with caching and elements may not be cleared properly. If you’re deploying Rails 4 assets on Heroku we cache these for you and the double caching actually SLOWS down your application.
I use turbo-sprockets (requires a custom buildpack) on Heroku on my Rails 3 app and it works great. Deploys are very fast.
-Jason
Serving in milliseconds
This is because sprockets doesn’t generate hashes, remove whitespace, compress javascript, or compile all JS to one file.
If you don’t need any of those things then don’t use the asset pipeline, store your assets in
/publicand serve them individually.
We do make use of the asset pipeline, quite heavily, and dev mode does put all assets into a single file. This is why I’m unsure why minify and hash should take so much time. The asset compile takes minutes in production.