在Rails生产中config.assets.compile = true，为什么不呢? [英] 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?
我不再需要运行precompile.我相信会发生的是第一次请求资产时，将对其进行编译.这将是第一次降低性能(这意味着您通常需要在生产环境中使用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运行时，并且愿意为资产的 first 访问权而降低性能，那么就不必运行precompile，有道理吗?
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?
推荐答案
我写了指南的那一部分.
I wrote that bit of the guide.
您绝对不希望在生产中进行实时编译.
You definitely do not want to live compile in production.
在进行编译时，会发生以下情况:
When you have compile on, this is what happens:
每个对/assets中文件的请求都传递给Sprockets.在对每个资产的 first 请求中，将其编译并缓存在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.
这是资产文件夹中的一切和插件所使用的任何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.
这使得具有正确指纹资产的页面的生成非常快，并且文件本身的提供是从文件系统的Web服务器快速进行的.两者都比实时编译快得多.
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编写资产的压缩版本，您可以将其设置为使用服务器，而无需为每个请求都这样做.
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.
这篇关于在Rails生产中config.assets.compile = true，为什么不呢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
