ruby-on-rails - Rails 生产中的 config.assets.compile=true ，为什么不呢？

Question

由 rails new 安装的默认 Rails 应用在生产环境中具有 config.assets.compile = false。

通常的做法是在部署应用程序之前运行rake asset:precompile，以确保所有 Assets 管道 Assets 都已编译。

那么如果我在生产环境中设置 config.assets.compile = true 会发生什么？

我不再需要运行预编译。我相信将会发生的是，第一次请求 Assets 时，它将被编译。这将是第一次对性能造成影响(这意味着您通常需要在生产中使用 js 运行时来执行此操作)。但除了这些缺点之外，在 Assets 被延迟编译后，我认为对该 Assets 的所有后续访问都不会受到性能影响，应用程序的性能将完全符合与此初始首次命中延迟编译后的预编译资源相同。 这是真的吗？

我有什么遗漏的吗？还有其他原因不在生产中设置 config.assets.compile = true 吗？如果我在生产环境中有一个 JS 运行时，并且愿意为 Assets 的首次访问而付出性能下降的代价，以换取不必运行预编译，这有道理吗？

Answer 1

我写了这部分指南。

您绝对不想在生产环境中进行实时编译。

当你编译时，会发生以下情况:

对/assets 中文件的每个请求都会传递到 Sprockets。在对每个 Assets 的第一个请求中，它被编译并缓存在Rails用于缓存的任何地方(通常是文件系统)。

在后续请求中，Sprockets 收到请求后必须查找指纹文件名，检查组成 Assets 的文件(图像)或文件(css 和 js)是否未被修改，然后是否有缓存版本服务于此。

这是插件使用的 Assets 文件夹和中的所有内容。

这是很大的开销，因为说实话，代码没有针对速度进行优化。

这会影响 Assets 通过网络传输到客户端的速度，并对网站的页面加载时间产生负面影响。

与默认值比较:

当 Assets 预编译并且编译关闭时， Assets 将被编译并指纹到public/assets。 Sprockets 将普通文件名到指纹文件名的映射表返回给 Rails，Rails 将其写入文件系统。 list 文件(Rails 3 中的 YML 或 Rails 4 中具有随机名称的 JSON)在启动时加载到 Memory by Rails 中并缓存以供 Assets 帮助器方法使用。

这使得具有正确指纹 Assets 的页面生成速度非常快，并且文件本身的服务速度很快。两者都比实时编译快得多。

为了获得管道和指纹识别的最大优势，您需要在 Web 服务器上设置远期 header ，并为 js 和 css 文件启用 gzip 压缩。 Sprockets 编写 Assets 的压缩版本，您可以将其设置为服务器使用，从而无需为每个请求执行此操作。

这可以尽可能快地将资源以尽可能小的尺寸发送给客户端，从而加快页面的客户端显示速度，并减少(使用远期 header )请求。

所以如果你正在实时编译它是:

1. 非常慢
2. 缺乏压缩
3. 会影响页面的渲染时间

对比

1. 尽快
2. 压缩
3. 删除从服务器监听到的压缩(可选)。
4. 最大限度地缩短页面的渲染时间。

编辑:(后续评论的答案)

管道可以更改为在第一个请求时进行预编译，但这样做存在一些主要障碍。首先，必须有一个用于指纹名称的查找表，否则辅助方法太慢。在按需编译的情况下，在编译或请求每个新资源时，需要某种方式附加到查找表。

此外，在所有 Assets 都编译并就位之前，有人必须在未知的时间内付出 Assets 交付缓慢的代价。

默认情况下，编译所有内容的费用一次性离线支付，不会影响公众访问者，并确保一切在上线之前正常运行。

最大的问题是它给生产系统增加了很多复杂性。

[编辑，2015 年 6 月] 如果您正在阅读本文是因为您正在寻找部署期间编译速度慢的解决方案，那么您可以考虑在本地预编译 Assets 。有关这方面的信息位于 asset pipeline guide 。这允许您仅在发生更改时才在本地预编译，提交该更改，然后无需预编译阶段即可快速部署。