WCF服務和超時

Question

，我就一直在生產工作幾年的應用，但在提高頻率已經expericing的UI（ASP的WebForms）和服務（WCF）之間超時。自從我們推出以來，用戶數量和數據量已經顯着增加。

本來，我們將原因歸結到業績不佳的SQL Server羣集（該服務使用），並遷移到一個更強大的集羣。但是，問題依然存在，並且似乎越來越多，我們每天收到的超時時間越來越長。

我們聘請了我們的DBA，但無法隔離SQL Server上的瓶頸。我還通過測試控制檯應用程序直接調用服務來執行測試，並且問題也出現在那裏，導致我認爲問題不在WebForms中，而是在於WCF服務。

我就如何解決這一理論（並開始解決它）損失，因爲它只有在看似高流量的情況下出現。

是否有與WCF和可擴展性的已知問題，或者是更有可能的是目前實施的服務是有缺陷？

Answer 1

我懷疑這個問題與SQL服務器和應用層之間的交互有關。我會假設你沒有在應用程序中使用APM，因爲你沒有提及它。更不用說，在大多數人的腦海裏，APM是爲了加快UI的工作，對嗎？

科學位，集中

ASP.Net/IIS默認給你的線程數量有限。記住線程是昂貴的，每個線程佔用調度程序時間並以各種棧的形式佔用內存，什麼不是。這幾乎是世界上所有計算機的缺陷。

在.NET中，所有工作都是在線程上完成的。因此，當沒有空閒線程時，IIS會將請求放入隊列以等待線程。現在，通常你會想如果所有的線程都在使用中，我們會有很高的CPU利用率。這是錯誤的。通常對於現代CPU，大部分時間他們都是I/O餓死，這意味着他們正在睡覺。

在這種情況下，一般什麼情況是幾個請求進來，自己的線程，誰然後打數據庫的每個球。然後他們等待（睡眠）。您的CPU使用率爲0％，而您的所有線程都在使用中。更多的請求進來了，他們被放入隊列中。數據庫請求返回，並且一些請求被出隊（但不是全部）。然後隊列上的請求超時。

Moar Thread！

我們如何解決這個問題？顯然，我們希望儘可能快地從IIS隊列中取出儘可能多的工作，並將其轉移到SQL服務器上，對吧？所以顯然的答案是增加線程的數量，對吧？現在，正如我前面提到的那樣，線程很昂貴，所以如果你有一個強大的SQL服務器，你的應用服務器仍然會在SQL服務器之前放棄這個幽靈，同時還有0％的CPU util。顯然更多的線程不會讓我們在我們想要的地方。

異步/等待神奇醬！

接受的解決方案是實際使用異步編程。

但是不是異步/等待UI和並行？

不是。它最經常在用戶界面和並行化方面得到證明，因爲它的獲益最容易形象化。在1小時的演示中更難以模擬1M次點擊/秒的服務。

因此，當我們向數據庫發送一個查詢，而不是在結果上休眠時，該線程跳轉回IIS隊列爲下一個客戶提供服務。當結果返回時，通知下一個可用線程並處理它。

因此，通過數據庫調用的異步/等待，您可以最大化CPU /網絡實用程序並忽略數據庫延遲。事實上，你會發現你應該將瓶頸轉移到SQL服務器上。

但我的API在哪裏？

啊......這是問題所在。異步/等待是相當新的。你需要VS 2012和.net 4.5（以及sorta）來使用它。大多數數據庫API還沒有完全支持Async/Await。

例如實體框架，Microsoft的旗艦數據庫技術只支持EF 6.0 ALPHA中的異步/等待（截至編寫本文時），並且很可能僅適用於MS SQL SERVER。