2012-08-30 52 views
6

環境:Windows Server 2003; IIS 6,ASP.NET 2.0.50727iis啓動延遲與aspx頁面

我對我們設置的一個全新的Web服務器感到瘋狂(請注意,這個問題在我們其他具有相同配置的Web服務器上不會發生)。當第一次加載和asp.net應用程序時,該頁面會在瀏覽器中顯示頁面之前掛起整整一分鐘。加載第一頁之後,所有內容都運行得非常快。

注1:您可能會說該應用程序正在進行首次編譯。但我已經排除了。我將跟蹤消息放在應用程序中,並且所有跟蹤消息都在請求頁面的一秒鐘內運行。因此,該應用程序立即編譯並運行。但是當應用程序完成渲染頁面並打印了最後的跟蹤消息時,沒有任何反應。在將完成的頁面沿着http傳輸到用戶的瀏覽器之前,IIS正在幕後做一些事情。注意2:我們發現在第一次點擊應用程序並且事情運行正常後,如果我們等待一個小時,我們會再次得到延遲。因此,IIS在緩存中有一些東西在一小時後清除,並導致我們的站點再次停頓。注意3:在每次測試之間,我們停止/啓動IIS以強制它在加載應用程序時掛起。注意4:我們觀察了任務管理器,看看IIS是否正在觸發並佔用大量資源來處理某些事情。但事實並非如此。在瀏覽器顯示頁面之前,我們確實看到了一個非常快的峯值,達到50%,但在之前的60秒內,服務器上只有1%的使用率。

注意5:在另一個測試中,我創建了一個HelloWorld.html頁面,這不會導致IIS掛起。因此,這與第一次通過http發送渲染頁面時調用ASP.NET庫有關。另外,由於該應用程序已經被編譯並立即運行,它只是asp.net的一部分,它將渲染後的頁面發送給用戶的瀏覽器,導致延遲。

任何想法?我們在這裏是一個損失。我們所有的其他網絡服務器都是以相同的方式安裝並且工作正常,但這是一個新的安裝。所以必須有一個配置設置被遺漏或者需要安裝?

感謝,

布賴恩

+0

你讀過關於事件查看器的任何asp.net錯誤嗎?您必須至少有一些超時事件 - 並關閉來自客戶端的連接,從而導致線程中斷。 – Aristos

+0

我們看了一下事件查看器,但沒有看到任何東西。我會做更多的測試並再次觀看。此外,除了我們的測試,此服務器沒有流量。所以沒有客戶放棄線程或類似的東西。只是我們做簡單的頁面請求和觀看是掛起的。 – user441058

+0

另一個問題可能是快速池重置,您可能具有類似的配置,但池中的設置可能不同。如果您在內存增長或太快等情況下重新啓動它們,請檢查它們。 – Aristos

回答

0

難道說是與衆不同此框一些aspnet.config設置。你有沒有試過把他們的配置文件複製到這個服務器上?似乎有證書選項與註冊表修改,你可以做一個頁面初始加載過程中去除一定的滯後時間(預編譯除外)沿

herehere

+0

aspnet.config文件是相同的(而且非常簡單)。 [代碼] <?XML版本= 「1.0」 編碼= 「UTF-8」?> <結構> [/ code] – user441058

1

如果你有訪問服務器,然後確保應用程序池回收實際上是記錄到事件日誌

CSCRIPT ADSUTIL.VBS獲取w3svc/AppPools /默認應用/的LogEventOnRecycle

,你可以將其設置爲記錄所有與 CSCRIPT adsutil.vbs設置w^3svc/AppPools /默認應用/的LogEventOnRecycle 255

See more here

然後檢查是否有任何再循環。

應用程序初始化,創建工作進程,線程,加載應用程序域和所有引用dll的可能需要一些時間,這是正常的,但1分鐘的延遲可能是別的東西。

嘗試預編譯服務器上的應用程序,看看是否有幫助 aspnet_compiler -m/LM/SVC/[網站編號] /根/ [您的應用程序的名字]

如果您想更深入,你可以檢查事件跟蹤ETW。

  1. logman查詢提供
  2. 保存IIS /ASP.NET相關的GUID的文件中像iisproviders.txt
  3. logman開始ExampleTrace -pf iisproviders.txt -ets -rt
  4. 重現
  5. LOGPARSER的 「SELECT * FROM ExampleTrace」 -i:ETW
  6. logman停止ExampleTrace -ets

你可以在這裏找到更多Troubleshooting appdomain restarts and other issues with ETW tracing

我還會檢查w3wp.exe與procexp,如果它有一個TCP連接超時或與其他線索與Procmon。

如果你有經驗的WinDbg,那麼你可以對應用程序的請求,然後調試器快速連接到過程

windbg -p [process id of the app pool] 
.loadby sos mscorwks 
g 

,並從那裏。如果有例外,進程崩潰等,你應該能夠趕上它...

一旦我們有這樣一個奇怪的服務器問題和.NET重新安裝解決了問題,仍然不知道是什麼罪魁禍首。

0

你可能想要檢查的一件事是如果有任何數據庫訪問正在你的頁面加載進行。這可能會阻止在初始頁面加載期間創建頁面。然後,當查詢被緩存時(通過數據庫引擎或memcached等其他緩存機制),後續頁面加載將正常工作。

按你最後的評論,

我會停止/啓動IIS多次和應用程序總是立刻跑了。我認爲這是固定好的。但現在我又試了一次(過去幾個小時一直閒置),現在又回到了第一次請求。

這可能意味着緩存已過期,因此需要再次訪問數據庫,導致頁面加載延遲。