页面间歇性地需要 2 分钟才能加载答案

【问题标题】：Page intermittently takes 2 minutes to load页面间歇性地需要 2 分钟才能加载
【发布时间】：2009-12-08 11:12:54
【问题描述】：

我们正准备将我们的 ASP.Net 应用程序切换到新的网络农场环境。但是，我们的测试发现了一个间歇性问题，即一个页面最多需要 2 分钟才能完成加载，而通常需要不到 2 秒的时间。浏览器诊断工具（如 Firebug）显示延迟发生在页面加载 jQuery 库和我们的样式表时。我真的不认为这些文件有问题，但我真的不知道问题是什么，所以我不能确定。

这里有一些关于我们环境的更多信息。我们的网络服务器运行 Windows Server 2008（64 位）、IIS 7、.Net 3.5。我们正在使用配置为将流量发送到当前负载最小的任何服务器的 Cisco CSS 负载均衡器（即负载均衡器不使用粘性会话）。 Web 服务器配置为使用第三台服务器作为会话存储（第三台服务器正在运行 ASP.Net 会话状态服务）。

关于什么可能导致延迟的任何想法？

更新：

感谢您迄今为止的回复。在回答给出的一些建议时，我可以肯定地说问题不是由于初始页面加载或任何繁重的第 3 方控制。我们可以连续点击页面多达 100 次，没有延迟，然后突然延迟发生在我们点击它的第 101 次。此外，这可能是一个重要的线索......当延迟发生时，我可以立即在浏览器上点击重新加载，页面将返回到它的快速加载时间......这会更多地指向网络/DNS 问题吗？

更新 2：

似乎只有在下载 jQuery 库时才会出现该错误。我敢肯定，大部分时间它都是从本地缓存中获取的，但即使本地副本已过期并下载新副本，下载一个仅约 56KB 的缩小 jQuery 库也不应花费 2 分钟大小。

更新 3：

在尝试 Fiddler（第一次）后，我能够重现该问题。这次从服务器下载图像文件时发生延迟。而且，它发生在我们的旧服务器上运行时 - 而不是网络农场！这是提琴手对那个文件所说的话。关于从中得出什么结论的任何想法？

Request Count:  1
Bytes Sent:     753
Bytes Received: 242

ACTUAL PERFORMANCE
ClientConnected:    19:53:15:5921
ClientDoneRequest:  19:53:15:8421
Gateway Determination:  0ms
DNS Lookup:         0ms
TCP/IP Connect:     31ms
ServerGotRequest:   19:55:25:7640
ServerBeginResponse:    19:55:25:7952
ServerDoneResponse: 19:55:25:7952
ClientBeginResponse:    19:55:25:7952
ClientDoneResponse: 19:55:25:8108

    Overall Elapsed:    00:02:10.2187500

RESPONSE CODES
HTTP/304:   1

RESPONSE BYTES (by Content-Type)
~headers:   242

响应头如下：

HTTP/1.1 304 Not Modified
Cache-Control: max-age=2592000
Last-Modified: Tue, 04 Aug 2009 05:11:20 GMT
Accept-Ranges: bytes
ETag: "ed5bca0c214ca1:f3a"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Tue, 08 Dec 2009 02:55:37 GMT

【问题讨论】：

感谢您告诉我...完成了。

标签： asp.net iis-7

【解决方案1】：

您可以使用 Fiddler 和/或 WireShark 来缩小问题范围。

可能的候选人：DNS 问题、第一次填充缓存的大型后端数据库查询、某种超时、错误配置的负载平衡器、首次访问时对 ASP.NET 代码的初始编译（已完成默认情况下基于每个文件夹），网络错误 - 并且列表继续。

【讨论】：

好的。我使用了 Fiddler 并能够重现该问题。我在上面的“更新 3”下发布了结果。

【解决方案2】：

您是否考虑过从另一个为此目的配置的网络服务器提供静态文件 - 可能在不同的域中？

【讨论】：

【解决方案3】：

我通常使用 Fiddler/Charles/HttpWatch（基本免费）之类的工具来解决这个问题，尽管 firebug 也同样出色。页面发出多少请求？您是否使用任何有时可能很重的第三方控件（例如 Telerik）。可能是您的应用程序/页面很重，并且它是该页面的第一次点击？您是否在客户端缓存静态资源（过期标头）？

【讨论】：

【解决方案4】：

我建议您冷启动应用程序，看看一般需要多长时间才能启动它。您可以通过循环支持虚拟目录的应用程序池来做到这一点。可能发生的情况是应用程序池在 20 分钟不活动后超时并被卸载。如果是这种情况，第 101 个请求可能正在重新启动它，并且可能存在耗时的预热程序。如果您发现是这种情况，我建议您创建一个简单的保活程序，以确保应用程序始终处于温暖状态。您可以通过安排一个任务来浏览您网站上具有无缓存元标题的 URL。

【讨论】：

感谢您的建议。回收应用程序根本不会导致明显的延迟。在我们的旧服务器上，回收可能会导致最多 30 秒的延迟，但新服务器显然要快得多。

【解决方案5】：

值得排除的一件事是，如果应用程序域被回收，导致整个应用程序不得不再次重新启动（这是两分钟，大致是整个应用程序从冷启动所需的时间吗？）。

有几件事可能导致此问题，包括 IIS 决定根据其应用程序池设置（内存阈值、回收时间等）回收应用程序池，或者由于未处理的异常一直冒泡到顶部。

检测此恕我直言的最快方法是在服务器上运行 Sysinternals 的 Process Explorer，然后从 .Net 列选项卡中添加“Total AppDomains”列。现在密切关注相关的 asp.net 进程。如果每次您遇到两分钟延迟时，总应用程序域计数都会增加，那么这是由于应用程序域回收。

【讨论】：

感谢您的建议，但我想我也可以排除这一点。目前，应用程序池设置为每 1740 分钟回收一次（必须是默认设置，因为我们还没有调整这些设置）。初始应用启动从未花费 2 分钟...可能最多 30 秒。

【解决方案6】：

您说您处于网络农场环境中。我会绕过负载均衡器直接连接到农场的每个盒子。这样您就可以测试每个盒子的响应能力。可能只有场中的一个盒子引起了问题，也可能是负载均衡器。

【讨论】：