頁面間歇性地需要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分鐘才能加載

回答

相關問題