Azure 网站上脚本/样式的长时间等待 (TTFB) 时间答案

【问题标题】：Long waiting (TTFB) time for scripts / styles on Azure WebsiteAzure 网站上脚本/样式的长时间等待 (TTFB) 时间
【发布时间】：2015-10-14 20:29:06
【问题描述】：

我在 Azure 网站上遇到了这个有趣的问题。我的网站使用 4 个脚本文件和 3 个样式文件，每个文件都缩小了。它们不是那么大，最大的有近 200 KB。网站已经开始了。 Azure 的 Always On 选项已打开。当我调用 WebApi 获取数据时，它会在

当重新加载应用程序时，它需要 250 毫秒才能从最小的脚本中获取第一个字节，而其他应用程序则需要更多时间。初始 Html 在 60 毫秒内加载。脚本/样式被缓存，因此它们不会被下载，但 TTFB 时间正在扼杀性能。这会重复每次重新加载。应用程序不包含任何复杂的配置，因此它应该运行得比它快得多。

什么会导致这些问题？

【问题讨论】：

你从 DenverCoder9 中发现了什么？你看到了什么？
请提供更多关于您的情况的信息。您使用的是哪个版本的 asp.net mvc？有什么配置吗？这是否也发生在 localhost 或仅在 Azure 上？
@ManosPasgiannis 赏金 - 仅限 Azure，最新的 MVC（不是 vNext），但文件是静态的，不通过它提供。
那么，文件根本没有服务？如果是这种情况，是否所有文件类型或其中一些文件类型都会发生这种情况？你对这些文件使用捆绑包吗？
请看stackoverflow.com/questions/29373297/…

标签： asp.net asp.net-mvc azure azure-web-app-service

【解决方案1】：

尽管您的静态文件已被缓存，但浏览器仍会发出带有 if-modifies-since 标头的请求（这会导致 304）。

虽然不需要下载实际内容，但仍需要等待 RTT + 服务器思考时间才能继续。

我建议两件事：

添加 Cache-Control 和 Expire 标头 - 在某些情况下有助于避免 304（除非您按 F5，否则几乎可以避免）
使用适当的 CDN - 例如 Incapsula 或其他，这将最大限度地减少 RTT + 思考时间。它还可用于轻松控制各种资源的缓存设置。

这里有更多好东西。

祝你好运！

【讨论】：

【解决方案2】：

来自here：

如您之前所见，IIS 7 缓存了静态的压缩版本文件。所以，如果一个请求到达一个静态文件的压缩版本已经在缓存中，不需要压缩再次。

但是如果缓存中没有压缩版本怎么办？将 IIS 7 然后立即压缩文件并将其放入缓存中？答案是的，但前提是文件被频繁请求。通过不压缩仅不经常请求的文件，IIS 7 保存 CPU 使用率和缓存空间。

默认情况下，如果文件被频繁请求，则认为该文件被频繁请求每 10 秒请求两次或更多次。

因此，为您的用户提供未压缩版本的 javascript 文件的原因是它不符合压缩的默认阈值；也就是说，javascript 文件在 10 秒内没有被请求 2 次。

要控制这一点，我们必须更改 <serverRuntime> 元素上的一个属性，该属性控制压缩：frequentHitThreshold。为了让您的文件在被请求一次时被压缩，请将您的 <serverRuntime> 元素更改为如下所示：

<serverRuntime enabled="true" frequentHitThreshold="1" />

如果您有许多正在提供的 javascript 文件并且您经常拥有用户，这将略微影响您的 CPU 性能，但如果您的用户经常足以影响 CPU 压缩这些文件，那么它们可能已经被压缩和缓存！

【讨论】：

【解决方案3】：

我的猜测是 Azures 会一直开启。
如果它像 CloudFlare 提供的那样工作，它实质上会代理请求并尝试缓存它。
根据 Azure 端缓存的具体实现，它可能会等待脚本输出完成以缓存它/验证缓存，然后将其传递给浏览器。

如果可能，您可能有机会检查缓存配置并为您的脚本禁用始终开启。

【讨论】：

【解决方案4】：

脚本和样式是静态文件，默认情况下会在发送到客户端之前进行压缩（您可以使用 HTTP 标头“content-encoding”：gzip 进行检查）。因此，TTFB 由网络延迟、浏览器 HTTP 通道调度和来自服务器的静态文件压缩时间组成。

另一方面，您的 Web API 数据是动态数据，默认情况下未压缩，因此其 TTFB 可能小于静态文件的 TTFB。

但是，您不需要关闭静态压缩，否则会最小化 TTFB，但会延长内容传输时间。其实，你不必担心 TTFB，查看更多信息：https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/

【讨论】：

两者都被压缩了。

【解决方案5】：

我完成了在 Azure 存储上存储文件并通过 Azure CDN 提供这些文件。它提供了高速响应并且不花费任何成本。在 Gulp 的 Pre-build 事件中，我将它们添加到每次发布的 blob 中。

【讨论】：

【解决方案6】：

嗯...您的网站存在 2 个主要问题：

您正在使用 AZURE - 一种性能不佳的高价服务....不要问我为什么人们认为这是一项很好的服务
您将客户端文件与服务器文件并排存储。而服务器文件应存储在特定服务器中，客户端文件实际上可以从... 无处不在

所以 - 请为您的客户端文件使用 CDN（或任何其他服务器）（主要是 css 和 js，您也可以考虑移动字体和图像）

【讨论】：