Heroku的導軌3.1應用程序 - 編制資產當地VS塞編譯

期間編制的資產，我運行的軌道在Heroku上雪松堆棧3.1應用程序，它支持資產的管道。 Heroku lists 3 ways來編譯資產Heroku的導軌3.1應用程序 - 編制資產當地VS塞編譯

顯然＃3對性能不利，Heroku文檔也建議不要。但我不確定＃1和＃2哪個更好。

＃1要求您運行rake assets:precompile並在git中包含您的public/assets文件夾。你的slu will會更大，但我認爲部署網站的停機時間會更短。但是更大的slu size大小意味着應用程序啓動速度較慢，所以也許這是一次洗牌

＃2將使其花費更長的時間來部署在Heroku上側正在做，因爲預編譯的更新。但是，你會有一個更小的slu and，而且管理/記憶更少。

我的問題是 - 哪個選項（＃1或＃2）是最適合生產的，爲什麼？

到目前爲止，它看起來像選項＃2，但我想確保我不忽視的東西。

2011-11-01 Dty

http://devcenter.heroku.com/articles/cdn-asset-host-rails31是一個很好看的太 - 雖然它同步資產S3從在Heroku您的應用程序，使他們仍然存在於你的蛞蝓只是沒有提供來自Heroku。 –

也有時＃2並不總是一種選擇。 Heroku總是會首先嚐試編譯它們，如果在運行時失敗的話。 –

我解決一些問題，在我的問題上大的疑難雜症在這裏：Rails 3.1.1 asset pipeline Heroku caching gotcha

我寧願＃2，如果它爲我工作，所以我沒有籤編制資產剛剛漲大的混帳庫。塞在編譯期間

編制資產不會導致任何額外的停機時間，因爲現有的應用程式會熬夜到一決高下編譯完成所以不用擔心那裏。

我的建議是＃2，如果你可以把它爲你工作。如果你最終以＃1的形式出現，那麼採取最佳做法是在耙子資產之前對rm -r public/assets進行git：預編譯以確保沒有剩餘。

2011-11-01 19:25:40

更新：升級到Devise 1.5後，選項＃2現在適用於我。0 - 比檢查資產更清潔。 –

如果你沒有其他選擇，只有＃1，創建一個Rake任務以部署到Heroku是一個好主意。它會1）刪除公共/資產2）預編譯資產3）簽入新編譯的資產git 4）推到heroku。＃ – Dty

＃2也是我的首選選項 - 但我一直很困惑，爲什麼它需要這麼長時間才能完成。它應該只是抓了十幾個文件和gziping。也許縮小需要最長的時間來檢查語法等？任何見解都會被讚賞 –

這可能取決於你的資產文件夾的大小，（也許一個長期的解決方案將是把這些資產在應用程序之外，並舉辦他們在S3等。）

否則，我假設由於任何資產都可以直接使用和緩存，因此＃1將是生產力最好的產品。

我正在閱讀Heroku關於assets的文檔部分，他們似乎表示，＃2將用於防止您忘記自己做，以方便。由於資產準備的結果將包含在slu to中以部署，因此您不會得到一小slu slu。

2011-11-01 06:25:14

非常有趣，slu size大小不小。感謝那些信息。但爲什麼在＃1中緩存與＃2不同？ – Dty

回答