Heroku rails 3.1 app - 在本地编译资产与在 slug 编译期间编译资产答案

【问题标题】：Heroku rails 3.1 app - compiling assets locally vs compiling assets during slug compilationHeroku rails 3.1 app - 在本地编译资产与在 slug 编译期间编译资产
【发布时间】：2011-12-19 06:25:58
【问题描述】：

我正在支持资产管道的 Heroku Cedar 堆栈上运行 rails 3.1 应用程序。 Heroku lists 3 ways 编译资产

在本地编译资产。
在 slug 编译期间编译资产。
在运行时编译资产。

显然#3 对性能不利，Heroku 文档也建议不要这样做。但我不确定 #1 和 #2 哪个更好。

#1 要求您运行 rake assets:precompile 并将您的 public/assets 文件夹包含在 git 中。您的 slug 会更大，但我认为部署站点的停机时间会更短。但更大的 slug 大小意味着应用程序启动速度较慢，所以可能是清洗。

#2 会延长部署更新的时间，因为预编译是在 Heroku 端完成的。但是，您的 slug 会更小，需要管理/记住的东西也会更少。

我的问题是 - 哪个选项（#1 或 #2）最适合生产，为什么？

到目前为止，它看起来像选项 #2，但我想确保我没有忽略某些东西。

【问题讨论】：

devcenter.heroku.com/articles/cdn-asset-host-rails31 也是一本不错的读物——尽管它会将资产从您在 Heroku 上的应用同步到 S3，因此它们仍然存在于您的 slug 中，只是没有从 Heroku 提供。
有时 #2 并不总是一个选项。 Heroku 总是会先尝试在 slug 编译期间编译它们，如果失败则在运行时编译。

标签： ruby-on-rails ruby ruby-on-rails-3 heroku asset-pipeline

【解决方案1】：

我在这里解决了其中一些问题和一个大问题：Rails 3.1.1 asset pipeline Heroku caching gotcha

如果它对我有用，我更喜欢 #2，这样我就不必检查只会使 git 存储库膨胀的编译资产。

在 slug 编译期间编译资产不会导致任何额外的停机时间，因为您现有的应用会一直运行到 slug 编译完成，所以不用担心。

如果你能让它为你工作，我的建议是#2。如果你最终选择了#1，那么最好的做法是在 rake assets:precompile 之前执行 git rm -r public/assets 以确保没有残留。

【讨论】：

更新：升级到 Devise 1.5.0 后，选项 #2 现在对我有效 - 比签入资产要干净得多。
如果您别无选择，只能 #1，最好创建一个 rake 任务以部署到 Heroku。它将 1) 删除公共/资产 2) 预编译资产 3) 将新编译的资产签入到 git 4) 推送到 heroku。
#2 也是我的首选 - 但我一直很困惑为什么它似乎需要这么长时间才能完成。它应该只是处理十几个文件并进行gziping。也许缩小检查语法等的时间最长？任何见解都值得赞赏。
@BrianArmstrong，我认为编译的最长部分是缩小是正确的。您可能想查看我的 turbo-sprockets-rails3 gem，它可以将您的资产：预编译时间减半。 (github.com/ndbroadbent/turbo-sprockets-rails3)

【解决方案2】：

这可能取决于您的资产文件夹的大小，（也许一个长期的解决方案是将这些资产放在应用程序之外并将它们托管在 S3 或类似设备上。）

否则，我认为 #1 将是生产中最好的，因为任何资产都可以立即使用和缓存。

我正在阅读 Heroku 在 assets 上的文档部分，它们似乎表明 #2 将用于以防万一您忘记自己做，以方便起见。您不会得到一个小的 slug，因为资产准备的结果将包含在 slug 中以自行部署。

【讨论】：

非常有趣的是蛞蝓尺寸并不小。谢谢你的信息。但是为什么 #1 中的缓存与 #2 不同呢？