2013-03-26 68 views
3

目前在我們的應用程序中,當執行第一個HTTP Webrequest時,我看到很大滯後。根據我們的日誌,有30-60秒的滯後。它會阻止在HttpWebRequest.BeginGetResponseHttpWebRequest.BeginGetResponse塊30-60秒

下面是從MSDN報價:

的BeginGetRequestStream方法需要一些同步設置任務 完成(DNS解析,代理檢測和TCP套接字 連接,例如)在這個方法變得異步之前。作爲 結果,不應在用戶界面(UI) 線程上調用此方法,因爲它可能需要一些時間(通常爲幾秒)。在 某些環境中,webproxy腳本未正確配置 ,這可能需要60秒或更長時間。配置文件元素上的 downloadTime屬性的默認值爲 一分鐘,這佔據了大部分潛在時間延遲。

我知道有DNS解析,代理檢測和其他所需的東西。但30-60秒太長了。當我在任何瀏覽器中輸入相同的URL時,我立即得到該頁面。當我解決DNS手冊時,也沒有任何延遲。 對同一個URI的所有併發請求都不會被阻塞。當我重新啓動應用程序時,第一個請求再次阻止最小值。 30秒。

這是一個已知的問題?有錯誤嗎?我們在不同的機器上看到這一點,所以我認爲我的開發人員機器不是問題。

下面是一些示例代碼:

private void TestWebRequest() 
{ 
    HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://matrix.ag-software.de/http-bind"); 
    request.ContentType = "text/xml; charset=utf-8"; 
    request.Method = "POST"; 
    request.BeginGetRequestStream(new AsyncCallback(GetRequestStreamCallback), request);    
} 

private void GetRequestStreamCallback(IAsyncResult result) 
{ 
    // 
} 

更新:這必須是我的Windows 7安裝的一個問題。我測試了2臺其他機器,並且不會在那裏導致相同的問題。我看到客戶的日誌文件具有完全相同的問題。這似乎發生在某些機器的某些條件下。

+0

這是針對內部網或互聯網網址嗎? – Justin 2013-03-26 14:26:20

+0

我添加了一些示例代碼。我有內部和外部的問題。也許它只是一個針對這個特定服務器實現的問題,可以通過一些特殊的設置來解決。 關於MONO我們沒有這個問題。目前我正在調試完整的.NET框架3.5。所有框架版本上都不存在該問題。例如Silverlight似乎工作正常,但它使用瀏覽器堆棧。 – Alex 2013-03-26 14:34:09

+0

你有沒有嘗試過,如果對任何其他網站,如谷歌或stackoverflow?它存在嗎? – Justin 2013-03-26 14:38:45

回答

0
+0

是的,我之前看過這些線程,但不知道這是否是完全相同的問題。這些線程是非常古老的,如果這是一個.NET問題,它應該已經在最新版本如3.5,4和4.5中修復。 – Alex 2013-03-28 11:46:56

+0

@Pete:你應該給出一個關於鏈接結論的摘要鏈接-O不允許回答。 – jgauffin 2014-04-25 11:55:43

1

我剛剛經歷了同樣的事情發生。

我發現Microsoft客戶端防火牆正在生成它。我正在使用它來避免瀏覽我公司的代理。我的第一個解決方法是設置request.Proxy硬編碼。爲了避免這種醜陋的代碼,我最終禁用了Microsoft客戶端防火牆並在Internet選項上設置了代理。

希望這會有所幫助。

正如@EricLaw所說,System.Net日誌記錄可能有所幫助。這裏是到MSDN的鏈接Enable System.Net logging

+0

代理緩慢檢測通常是請求延遲的原因。啓用S​​ystem.NET日誌記錄將有助於揭示這是否是特定.NET WebRequest性能問題的原因。 – EricLaw 2014-04-24 16:46:48

+0

謝謝@EricLaw。我會看一看,因爲我只有很少的URI需要這麼長時間。 – Diego 2014-04-25 11:50:54

相關問題