asp.net-mvc-3 - 带有 IE 的 MVC 3，捆绑性能较差

Question

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

• 为什么我需要 20 秒的响应时间来获取脚本包？

  

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

  

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

编辑：根据评论请求，我还包括捆绑请求标头：

Answer 1

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

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

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

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

你所知道的总结

看起来你有：

• Expires服务器从现在开始一年后发送一个标头
• 当您重新加载页面时（即您不强制使用 完全刷新Ctrl+F5）
  • IE doesn't take any notice of the cache header, and when it sends it's new request it doesn't use If-Modified-Since or If-None-Match
  • Chrome behaves differently and respects the Expires and/or ETag response headers (it doesn't even make the request again for the bundle).
• EDIT 1: You also seem to be saying (though it would be good to see a timeline from chrome) that Chrome downloads the files faster, implying it is not a server-side problem. Your latest comment states that Chrome's downloads are also slow. (end edit)
• And you also seem to be saying that this behaviour is consistent (i.e. 100 requests in IE, and 100 requests in Chrome show the above behaviour with no deviations).

Approach

You should break this problem into two parts:

1. Why is the download so slow?
   • Is there a server-side performance problem? Look for common download times in IE and Chrome, and Firefox (it could be due to bundling/minification/compression on the server).
   • Is there a network connectivity issue (dropped packets, for instance)? Look for inconsistent download times, Start times, Request times, between requests in a given browser and the same behaviour across all browsers.
   • Is a script slowing down IE, but not Chrome (this is not uncommon, I maintain legacy sites where the scripts don't run well in IE but do in Chrome) - look at different profile results between browsers.
2. Why is the javascript not being cached in IE? Troubleshoot (1) first, then worry about this.

It is possible that the two are related, but approaching them separately will be a start. Number 1 is far easier to diagnose that 2, the top references to caching javascript in IE on the web are to prevent it in order to help with development.

Root cause diagnosis

EDIT 1 The first thing to do is try the site from a browser on the server, or very close to the server to see if you have a network issue. (end edit)

Tools like Fiddler, the browser developer tools, timeline and script profiler, and YSlow are your friend. Compare each of the following between Chrome and IE (and see what happens in Firefox as well) and spot the difference. Note: you may need to clear the browser cache between tests.

• browser developer tools -> script profile: see if you have a slow running script in IE compared to Chrome
  • similar analysis in a tool like YSlow (look for comparisons between the two browsers, not script improvements)
• request and response headers, and timeline from a normal (i.e. not full reload) page load
• request and response headers, and timeline from a full page reload (Ctrl+F5)
• Start and Request durations for every js file for a given browser, and between browsers (this may point to network issues)? I note that the Start and Request alone are taking 0.6s and 1s each in IE - that is very very poor performance.
• 5 requests, and 5 full reloads with cache clearing between (that is, don't chase a ghost - be consistent in your test methodology)

Download times should be no different between Chrome and IE with no scripts actually running so also add a control test. Assuming that your bundle files don't "do anything" (i.e. they contain functions that the page calls rather than kicking off long processes by themselves) then create a blank page in your site which references exactly the same javascript files - not just the bundle, but every single js reference.

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