【问题标题】:MVC 3 with IE, poor bundle performance带有 IE 的 MVC 3,捆绑性能较差
【发布时间】:2024-05-20 06:45:02
【问题描述】:

我们在 IIS6 机器上部署了一个 MVC 3 网站。 一切运行良好,但性能糟糕透顶。 谁能帮我理解

  • 为什么我需要 20 秒的响应时间才能获得脚本包?

  • 为什么即使设置了 Expires 标头,IE 也不会缓存捆绑的脚本?

该网站在 Chrome 中的速度提高了几倍(我注意到缓存行为是正确的),但我们不能强迫客户使用它。 任何帮助都会很棒。我有点想知道是否是服务器端设置强制每个请求重新编译捆绑包,还是只是 IE 像往常一样行事。

编辑:根据 cmets 请求,我还包括捆绑请求标头:

【问题讨论】:

  • 能否也发布请求的图片?查看请求是否对脚本有任何先验知识可能会有所帮助(例如,它是否发送 If-Modified-SinceIf-None-Match
  • @AndyBrown - 谢谢!我将尽快包含请求屏幕截图。
  • 这很烦人 - 这些标题都不存在(我假设这是正常加载而不是完全刷新)。如果您在 Chrome 中点击 完全刷新 (Ctrl+F5),它是否会以相同的性能发生,或者该捆绑包下载是否以毫秒为单位(即,chrome 开发人员工具中的时间线是什么样的)
  • @AndyBrown - 刚刚在 Chrome 中测试。完全刷新包括一个 Pragma: no-cache 标头。之后,重新加载页面显示捆绑包是从缓存加载的,加载时间
  • 完全刷新下载包的速度有多快?

标签: asp.net-mvc-3 performance internet-explorer iis-6


【解决方案1】:

如果您在两个浏览器之间完全重新加载的下载时间不同,则可能是您正在使用 angularjs 之类的客户端框架进行密集计算(我已经看到高度复杂的 angularjs 应用程序之间存在巨大的性能差异两个浏览器)。

如果您的两个浏览器显示相同的下载时间,则可能是网络问题或服务器问题。

IE 缓存可能是一个单独的问题,请将您的问题分为两部分 - 首先查找下载缓慢的原因。

我现在所能做的就是提出一种解决问题的方法。

你所知道的总结

看起来你有:

  • 服务器在一年后发送Expires 标头
  • 当您重新加载页面时(即您不使用 Ctrl+F5 强制完全刷新)
    • IE 不会注意到缓存头,当它发送新请求时它不使用If-Modified-SinceIf-None-Match
    • Chrome 的行为不同,并尊重 Expires 和/或 ETag 响应标头(它甚至不会再次为捆绑包发出请求)。
  • 编辑 1您似乎也在说(尽管从 chrome 中看到时间线会很好)Chrome 下载文件的速度更快,这意味着它是 不是服务器端问题。 您最近的评论指出 Chrome 的下载速度也很慢。 (结束编辑)
  • 而且您似乎还说这种行为是一致的(即 IE 中的 100 个请求,Chrome 中的 100 个请求显示上述行为没有偏差)。

方法

你应该把这个问题分成两部分:

  1. 为什么下载这么慢?
    • 是否存在服务器端性能问题?在 IE、Chrome 和 Firefox 中寻找常见的下载时间(这可能是由于服务器上的捆绑/缩小/压缩)。
    • 是否存在网络连接问题(例如丢包)?在给定浏览器中的请求之间寻找不一致的下载时间、开始时间、请求时间,以及所有浏览器中的相同行为。
    • 是一个减慢 IE 速度的脚本,而不是 Chrome 速度(这种情况并不少见,我维护的旧网站中的脚本在 IE 中运行不佳,但在 Chrome 中运行良好) - 查看浏览器之间的不同配置文件结果。
  2. 为什么 IE 中没有缓存 javascript?先解决 (1) 问题,然后再考虑这个问题。

这两者可能是相关的,但分别接近它们将是一个开始。数字 1 更容易诊断 2,在网络上对 IE 中缓存 javascript 的主要参考是防止它以帮助开发。

根本原因诊断

编辑 1 首先要做的是从服务器上的浏览器中尝试该站点,或者非常靠近服务器,看看您是否有网络问题。 (结束编辑)

Fiddler、浏览器开发者工具、时间线和脚本分析器以及YSlow 等工具都是您的朋友。比较 Chrome 和 IE 之间的以下各项(并查看 Firefox 中的情况)并找出差异。注意:您可能需要在测试之间清除浏览器缓存

  • 浏览器开发者工具 -> 脚本配置文件:看看你在 IE 中运行的脚本是否比 Chrome 慢
    • YSlow 等工具中进行类似分析(寻找两个浏览器之间的比较,而不是脚本改进)
  • 请求和响应标头,以及来自正常(即非完全重新加载)页面加载的时间线
  • 请求和响应标头,以及来自完整页面重新加载的时间线 (Ctrl+F5)
  • StartRequest 给定浏览器的每个 js 文件的持续时间,以及浏览器之间的持续时间(这可能指向网络问题)? 我注意到 StartRequest 在 IE 中分别花费 0.6s 和 1s - 这是非常非常糟糕的性能。
  • 5 次请求和 5 次完全重新加载并清除缓存(也就是说,不要追逐幽灵 - 在您的测试方法中保持一致)

Chrome 和 IE 之间的下载时间应该没有什么不同,没有实际运行的脚本,所以还要添加一个控制测试。假设您的捆绑文件不“做任何事情”(即它们包含页面调用的函数,而不是自己启动长进程)然后在您的站点中创建一个空白页面,引用完全相同的 javascript 文件 em> - 不只是捆绑包,还有每个 js 引用。

通过控制测试,您可以比较 IE 和 Chrome 中的纯下载时间和缓存行为,而无需运行任何客户端 JavaScript(使用开发人员工具分析器来验证没有脚本在运行)。如果您的捆绑文件确实启动了长时间运行的东西,只需通过将 return 语句放在脚本顶部来暂时禁用这些东西,并只专注于下载到浏览器中。

【讨论】:

  • 惊人的答案,让我根据您的建议诊断问题,然后我将在这里发布我的发现。谢谢!编辑:在我忘记之前,关于你的第一点,我没有做任何特殊的客户端(没有模板库等)
  • 祝你好运。请注意,SO 并不是一个真正的“故障排除”网站——如果你想得到好的回应,请尝试将具体问题作为你更大问题的一部分提出,大多数人不会回答这样的问题,它甚至可能被关闭为OT。
  • 感谢您的建议。我没想到演练故障排除是诚实的,而是对这种行为的原因的解释/确认。据我所知,YSlow(评分:90)我认为我们可以同意这里的问题可能是服务器上传和 IE 缓存行为。这些是肯定可以分开解决的问题。我会将此标记为已回答,以免引起节制...感谢您的宝贵时间,非常感谢。
  • @Raine。这不是批评,我认为如果您将 MVC3 固定到服务器端,其他人可能会在 IIS6 上看到这种行为,因此您的解决方案应该记录在这里,而不是从 SO 中丢失。我的评论(尽量让您的问题尽可能具体地编程以避免关闭队列的愤怒)是旁白。