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

时间:2009-12-06 23:57:19

标签: asp.net iis-7

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

以下是有关我们环境的更多信息。我们的Web服务器运行的是Windows Server 2008(64位),IIS 7,.Net 3.5。我们使用Cisco CSS负载均衡器配置为将流量发送到当前负载最小的服务器(即负载均衡器不使用粘性会话)。 Web服务器配置为使用第三个服务器作为会话存储(第三个服务器正在运行ASP.Net会话状态服务)。

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


更新

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


更新2

下载jQuery库时似乎只会发生错误。我确信大部分时间都是从本地缓存中提取它,但即使本地副本过期并下载了一个新副本,也不需要花2分钟下载一个只有~56KB的缩小jQuery库大小。


更新3

在尝试了Fiddler(第一次)之后,我能够重现这个问题。这次从服务器下载图像文件时发生延迟。并且,在我们的旧服务器上运行时发生了这种情况 - 而不是网络农场!这是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

AND响应头如下:

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

6 个答案:

答案 0 :(得分:1)

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

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

答案 1 :(得分:0)

您是否考虑过为此目的配置的其他网络服务器提供静态文件 - 可能是在其他域?

答案 2 :(得分:0)

我通常使用像Fiddler / Charles / HttpWatch这样的工具(基本 - 这是免费的)来解决这个问题,虽然firebug也同样好。页面制作请求了多少?您是否正在使用任何有时可能很重的第三方控件(如telerik)。可能是你的应用程序/页面很重,它是该页面的第一个打击?你是否在客户端缓存静态资源(过期标题)?

答案 3 :(得分:0)

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

答案 4 :(得分:0)

值得排除的一件事是,如果应用程序域正在被回收,导致整个应用程序必须重新启动(这是两分钟,大致是整个应用程序从冷启动的时间?)。

有几件事可能会导致这种情况,包括IIS决定根据应用程序池设置(内存阈值,回收时间等)来回收应用程序池,或者由于未处理的异常从一直冒泡到顶部。

检测此IMHO的最快方法是在服务器上运行Sysinternals的Process Explorer,并从.Net列选项卡添加“Total AppDomains”列。现在请关注相关的asp.net进程。如果每次遇到两分钟延迟时,应用领域的总计数都会上升,那么这是应用域回收的原因。

答案 5 :(得分:0)

您说您处于Web场环境中。我会绕过负载均衡器直接连接到服务器场的每个盒子。这样您就可以测试每个盒子的响应能力。可能是服务器场中只有一个框导致问题,或者它是负载均衡器。

相关问题