查找ASP.Net超時原因（在漫長的操作過程中）

我有一個asp.net web應用程序。它通過WCF與業務層進行通信。有一個冗長的數據庫操作（花費兩個小時）。這是一個通常的同步呼叫。最初我曾經習慣了與WCF超時相關的異常。對於這些例外情況，以前在UI頁面中引發了異常（稱爲「套接字超時」）。我在服務和客戶端都使用WCF綁定設置解決了這個問題。查找ASP.Net超時原因（在漫長的操作過程中）

現在，（正好）一個小時後，我在瀏覽器窗口中出現錯誤。即使我們的應用程序有一個自定義的應用程序錯誤頁面，它也不會顯示自定義錯誤由於在UI中沒有拋出異常，我認爲它可能是由於ASP.Net超時而不是WCF造成的。我也沒有看到任何相關的登錄事件查看器。

我可以使用哪些方法/工具來確定超時的確切原因？

它是broswer設置/ asp.net設置/ iis設置問題？

IE錯誤信息：您正在查找的頁面當前不可用。該網站可能遇到技術問題，或者您可能需要調整瀏覽器設置。注意：在底部顯示「無法找到服務器或DNS錯誤」

注意：該功能僅在一個月內使用一次。這是管理員的功能。所以花兩個小時對我們來說沒問題。

注意：我有以下WCF配置。服務（receiveTimeout =「05:30:00」）和客戶端（receiveTimeout =「05:30:00」和sendTimeout =「05:30:00」）。

注意：無法導航到我們的自定義錯誤頁面，並且不會引發異常。

注：我使用Visual Studio 2005開發

注：WCF是自託管的測試。

注：在WCF NetTcpBinding的

在應用程序中使用的一些配置值列舉如下：

<httpRuntime maxRequestLength="20000" executionTimeout="900"/>

<forms loginUrl="Default.aspx" name=".ASPNETAUTH" protection="None" path="/" timeout="30" defaultUrl="Home.aspx"> 

    </forms> 

</authentication>

和 -

<roleManager defaultProvider="MyRoleProvider" enabled="true" 
cacheRolesInCookie="true" cookieName=".ASPROLES" cookieTimeout="30" cookiePath="/" cookieRequireSSL="false" cookieSlidingExpiration="true" cookieProtection="All"> 
    <providers> 
    <clear/> 
    <add name="MyRoleProvider" type="My.AccessControl.ServiceLayer.MyRoleProvider" /> 
    </providers> 
</roleManager>

注：我是計劃在IE中禁用'「顯示友好的HTTP錯誤消息」。我還計劃在system.web中使customErrors mode =「Off」對其進行進一步測試。

來源

2011-06-21 Lijo

考慮把它分成獨立的過程一個Web請求是不是要住2個小時... –

這是如何託管，在iis？還是開發者服務器？如果它在iis中可能檢查你的連接超時設置 –

你是否使用不同的瀏覽器得到相同的結果？ –

如果您可以託管它在IIS服務器上，您可以嘗試使用FailedRequestTracing模塊。

http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/

我已經使用了故障排除

之前超時。

來源

2011-06-21 19:20:22 snaits

當然，我會盡最大努力用FailedRequestTracing進行測試。與此同時，請您提供一些配置值，以便我可以查找潛在問題（可能是1小時的默認設置）？ – Lijo

會話是否超時或在一小時內關閉（網絡）應用程序？

來源

2011-06-21 21:01:42

第一個，瀏覽器只會等待這麼長時間才能讓Web服務器響應並開始產生響應。 IE 7/8，我相信60分鐘後保釋。關於IE 9不知道。詳情請見KB181050文章。在決定在服務器上沒有服務器之前，Firefox，Chrome，Safari，Opera都可能會在多長時間內願意等待。

坦率地說，我認爲在決定服務器不會回答之前，60分鐘等待很長時間。 5分鐘應該足夠了。如果您要求網頁並且沒有收到服務器超過一兩分鐘的任何響應，那麼您會假設什麼？您是否通常認爲服務器已被綁定並取消請求？

無論如何，當瀏覽器放棄請求時，它將關閉套接字，您將從瀏覽器中獲得錯誤頁面。你不會在服務器端看到任何東西：它仍然歡快地磨掉。不過，我認爲，IIS會在套接字丟失時發現。希望在那時IIS將終止請求。

第二個，IIS本身只會等待很長時間，然後才決定在請求處理過程中出現問題。我相信你應該得到一個例外。

爲什麼你會期望你的用戶（和他們的網絡瀏覽器）在HTTP請求上等待2+小時呢？

設置您的管理應用程序，以便像這樣的請求排隊並通過某種守護進程異步處理（或產生一個線程來執行異步處理。回傳某種票據，以便請求頁面可以定期輪詢以查看如果長時間運行的請求已經完成：在這一點上，返回任何構成請求的實際響應。

在客戶端瀏覽器上，通過AJAX帖子產生這樣的請求。讓客戶端JavaScript使用返回的票證每隔30秒鐘輪詢一次，直到請求完成。Voila！沒有更多瀏覽器超時。

來源

2011-06-21 21:27:30

您最好需要實現雙工服務WCF和ASP.net和AJAX之間通知客戶端和網絡服務器之間的通知

來源

2011-06-21 21:28:48 hungryMind

通過HTTP等待您自己描述爲兩小時操作的整個概念從git-go中是有缺陷的。正如其他海報所提到的，你需要重新思考你的策略。在一些排隊過程中踢出它，然後向用戶提供一些方法來輪詢完成，甚至向他們發送帶有鏈接的電子郵件通知是一種方式。

跟隨流程。

來源

2011-06-21 23:05:29

查找ASP.Net超時原因（在漫長的操作過程中）

回答

相關問題