config.assets.compile=true 在 Rails 生产中，为什么不呢? [英] config.assets.compile=true in Rails production, why not?
问题描述
rails new 安装的默认 Rails 应用程序在生产中具有 config.assets.compile = false.
The default Rails app installed by rails new has config.assets.compile = false in production.
通常的做法是在部署您的应用程序之前运行 rake assets:precompile，以确保编译所有资产管道资产.
And the ordinary way to do things is to run rake assets:precompile before deploying your app, to make sure all asset pipeline assets are compiled.
那么如果我在生产中设置 config.assets.compile = true 会发生什么?
So what happens if I set config.assets.compile = true in production?
我不再需要运行预编译.我相信会发生的是第一次请求资产时，它会被编译.这将是第一次的性能损失(这意味着您通常需要在生产中使用 js 运行时才能做到这一点).但除了这些缺点之外，在资产被懒惰地编译后，我认为对该资产的所有后续访问都将没有性能受到影响，应用程序的性能将完全相同与此初始首次命中延迟编译后的预编译资产相同.这是真的吗?
I wont' need to run precompile anymore. What I believe will happen is the first time an asset is requested, it will be compiled. This will be a performance hit that first time (and it means you generally need a js runtime in production to do it). But other than these downsides, after the asset was lazily compiled, I think all subsequent access to that asset will have no performance hit, the app's performance will be exactly the same as with precompiled assets after this initial first-hit lazy compilation. is this true?
有什么我遗漏的吗?在生产中不设置 config.assets.compile = true 的任何其他原因?如果我在生产环境中有一个 JS 运行时，并且愿意在第一次访问资产时牺牲性能下降的代价，以换取不必运行预编译，这有意义吗?
Is there anything I'm missing? Any other reasons not to set config.assets.compile = true in production? If I've got a JS runtime in production, and am willing to take the tradeoff of degraded performance for the first access of an asset, in return for not having to run precompile, does this make sense?
推荐答案
我写了那部分指南.
您绝对不想在生产中进行实时编译.
You definitely do not want to live compile in production.
当您进行编译时，会发生以下情况:
When you have compile on, this is what happens:
对/assets 中文件的每个请求都会传递给 Sprockets.在对每个资源的第一个请求时，它被编译并缓存在 Rails 用于缓存的任何地方(通常是文件系统)中.
Every request for a file in /assets is passed to Sprockets. On the first request for each and every asset it is compiled and cached in whatever Rails is using for cache (usually the filesystem).
在后续请求中，Sprockets 收到请求，必须查找指纹文件名，检查构成资产的文件(图像)或文件(css 和 js)是否未被修改，然后是否有缓存版本服务那个.
On subsequent requests Sprockets receives the request and has to look up the fingerprinted filename, check that the file (image) or files(css and js) that make up the asset were not modified, and then if there is a cached version serve that.
这就是assets文件夹和中的一切插件使用的任何vendor/assets文件夹中的内容.
That is everything in the assets folder and in any vendor/assets folders used by plugins.
老实说，这是很多开销，因为代码没有针对速度进行优化.
That is a lot of overhead as, to be honest, the code is not optimized for speed.
这将对资产通过线路传输到客户端的速度产生影响，并对您网站的页面加载时间产生负面影响.
This will have an impact on how fast asset go over the wire to the client, and will negatively impact the page load times of your site.
与默认值对比:
当资产被预编译并且编译关闭时，资产被编译并指纹到public/assets.Sprockets 将普通文件名到指纹文件名的映射表返回给 Rails，Rails 将其写入文件系统.清单文件(Rails 3 中的 YML 或 Rails 4 中具有随机名称的 JSON)在启动时由 Rails 加载到内存中，并缓存以供资产助手方法使用.
When assets are precompiled and compile is off, assets are compiled and fingerprinted to the public/assets. Sprockets returns a mapping table of the plain to fingerprinted filenames to Rails, and Rails writes this to the filesystem. The manifest file (YML in Rails 3 or JSON with a randomised name in Rails 4) is loaded into Memory by Rails at startup and cached for use by the asset helper methods.
这使得具有正确指纹资产的页面的生成速度非常快，并且文件本身的服务是来自文件系统的快速网络服务器.两者都比实时编译快得多.
This makes the generation of pages with the correct fingerprinted assets very fast, and the serving of the files themselves are web-server-from-the-filesystem fast. Both dramatically faster than live compiling.
要获得管道和指纹识别的最大优势，您需要在 Web 服务器上设置远未来的标头，并为 js 和 css 文件启用 gzip 压缩.Sprockets 编写了资源的 gzip 压缩版本，您可以将这些资源设置为使用您的服务器，从而无需为每个请求都这样做.
To get the maximum advantage of the pipeline and fingerprinting, you need to set far-future headers on your web server, and enable gzip compression for js and css files. Sprockets writes gzipped versions of assets which you can set your server to use, removing the need for it to do so for each request.
这会尽快将资产以尽可能小的尺寸提供给客户端，从而加快页面在客户端的显示速度，并减少(使用远期标题)请求.
This get assets out to the client as fast as possible, and in the smallest size possible, speeding up client-side display of the pages, and reducing (with far-future header) requests.
所以如果你是实时编译它是:
So if you are live compiling it is:
- 很慢
- 缺乏压缩
- 会影响页面的渲染时间
对比
- 尽快
- 压缩
- 删除从服务器中听到的压缩(可选).
- 最小化页面的渲染时间.
(回答后续评论)
管道可以更改为在第一个请求时进行预编译，但这样做有一些主要障碍.首先是必须有一个用于指纹名称的查找表或辅助方法太慢.在按需编译的情况下，需要通过某种方式在编译或请求每个新资产时附加到查找表.
The pipeline could be changed to precompile on the first request but there are some major roadblocks to doing so. The first is that there has to be a lookup table for fingerprinted names or the helper methods are too slow. Under a compile-on-demand senario there would need to be some way to append to the lookup table as each new asset is compiled or requested.
此外，在所有资产都被编译和到位之前，有人将不得不为一段未知的时间段内缓慢的资产交付付出代价.
Also, someone would have to pay the price of slow asset delivery for an unknown period of time until all the assets are compiled and in place.
默认情况下，编译所有内容的费用是一次性离线支付的，不会影响公众访问者，并确保一切正常运行.
The default, where the price of compiling everything is paid off-line at one time, does not impact public visitors and ensures that everything works before things go live.
破坏交易的是它给生产系统增加了很多复杂性.
The deal-breaker is that it adds a lot of complexity to production systems.
如果您正在阅读本文是因为您正在寻找部署期间编译时间缓慢的解决方案，那么您可以考虑在本地预编译资产.资产管道指南中提供了相关信息.这允许您仅在发生更改时在本地预编译，提交该更改，然后在没有预编译阶段的情况下进行快速部署.
If you are reading this because you are looking for a solution for slow compile times during a deploy, then you could consider precompiling the assets locally. Information on this is in the asset pipeline guide. This allows you to precompile locally only when there is a change, commit that, and then have a fast deploy with no precompile stage.
这篇关于config.assets.compile=true 在 Rails 生产中，为什么不呢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
