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

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

下面是关于我们的环境的更多信息。我们的Web服务器运行Windows Server 2008（64位），IIS 7，.Net 3.5。我们使用Cisco CSS负载均衡器配置为将流量发送到当前负载最轻的服务器（即负载均衡器未使用粘滞会话）。 Web服务器配置为使用第三台服务器作为会话存储（第三台服务器正在运行ASP.Net会话状态服务）。

任何有关可能导致延迟的想法？

UPDATE：

感谢您的答复迄今。回答一些建议，我可以肯定地说这个问题不是由于初始页面加载或任何沉重的第三方控制。我们可以毫不拖延地连续打100页，然后在我们第101次点击它时突然发生延迟。此外，这可能是一个重要的线索......当延迟发生时，我可以立即在我的浏览器上重新加载，并且页面将返回到它的加载时间快......这是否意味着更多地面对网络/ DNS问题？

更新2：

这似乎是错误在下载jQuery库只有永远发生。我确定大部分时间都是从本地缓存中选择它，但即使本地副本过期并且下载了新副本，也不需要2分钟即可下载大小仅为〜56KB的jQuery库在尺寸方面。

更新3：

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

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

来源

2009-12-06 chief_wampum

谢谢你让我知道...完成。 – 2009-12-07 07:49:44

你有没有考虑将从配置为该目的另一个网站服务器提供静态文件 - 在不同的域名吧？

来源

2009-12-07 00:50:55

我通常使用像Fiddler/Charles/HttpWatch（基本 - 这是免费的）工具来解决这个问题，虽然萤火虫也同样好。网页制作有多少请求？你是否在使用任何第三方控件（如telerik），有时这些控件可能很重。可能是你的应用程序/页面很重，它是该页面的第一个命中？你是否缓存客户端的静态资源（expires头文件）？

来源

2009-12-07 01:43:52 ram

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

可能的候选人：DNS问题，第一次填满缓存的大型后端数据库查询，某种类型的超时，配置错误的负载平衡器，第一次访问时初次编译ASP.NET代码（它是默认情况下按文件夹完成），网络错误 - 并继续进行。

来源

2009-12-07 03:14:40 RickNZ

好的。我使用了Fiddler并能够重现问题。我在上面的“更新3”中发布了结果。 – 2009-12-08 03:06:46

我建议你做一个冷启动的应用程序，看看需要多长时间才能启动它。您可以通过循环支持虚拟目录的应用程序池来完成此操作。可能发生的情况是应用程序池超时并在闲置20分钟后卸载。如果是这样的话，第101个请求可能会重新启动它，并且可能会有变暖的程序，这是耗时的。如果您发现这种情况，我建议您创建一个简单的保持活动过程，以确保应用始终处于温暖状态。您可以通过计划任务来浏览网站上具有无缓存元标题的网址。

来源

2009-12-07 17:37:48

感谢您的建议。回收应用程序导致无法察觉的延迟。在我们的旧服务器上，回收可能会导致长达30秒的延迟，但新服务器显然要快得多。 – 2009-12-07 18:03:53

有一点非常值得排除的是，如果应用程序域正在被回收，导致整个应用程序不得不重新启动（这是两分钟，大致是整个应用程序从寒冷开始的时间？）。

几件事情可能导致这种情况，包括IIS根据其应用程序池设置（内存阈值，回收时间等）决定回收应用程序池，或者由于未处理的异常冒泡到整个顶部。

检测这个恕我直言的最快方法是在服务器上运行Sysinternals的Process Explorer，并从.Net列标签中添加“Total AppDomains”列。现在请关注相关的asp.net进程。如果每次遇到两分钟的延迟时间，应用程序域总数就会增加，那么这是由于应用程序域回收所致。

来源

2009-12-07 17:40:32

感谢您的建议，但我想我也可以排除这一点。目前，应用程序池每1740分钟设置为回收（必须是默认值，因为我们尚未调整这些设置）。最初的应用程序启动从来没有采取2分钟...可能高达30秒的上衣。 – 2009-12-07 17:59:04

你说你在网络农场环境。我会直接连接到场的每个盒子，绕过负载平衡器。这样你可以测试每个盒子的响应度。可能只有一个服务器场引发了问题，或者它是负载平衡器。

来源

2009-12-07 20:07:51

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

回答

相关问题