.NET HttpClient導致Http連接變慢或死鎖

Question

我們有一個ASP.NET WebAPI應用程序，該應用程序需要向其他Web應用程序發出很多調用（它基本上是反向代理）。 為此，我們使用HttpClient的異步方法。

是的，我們已經看到了有關僅使用一個HttpClient實例而不丟棄它的提示。

是的，我們已經看到了有關設置配置值的提示，尤其是租用超時問題。 當前，我們設置ConnectionLimit = CPU * 12，ConnectionLeaseTimeout = 5min，MaxIdleTime = 30s。

我們可以看到連接的行為符合預期。 負載測試中的吞吐量也非常好。 但是，我們面臨的問題是，有時連接會停止工作。 這似乎發生在有大量請求傳入時（並且是反向代理，導致發出了新請求），並且大多數情況下（但不僅如此）發生在所有后端應用程序中最慢。 這樣的行為是，要花很長時間才能完成對該端點的請求，否則它們只會以超時結束。

托管我們的反向代理應用程序的服務器的IISReset會終止問題（一段時間）。

我們已經在幾個領域進行了調查：

• 遠程Web應用程序的性能問題：盡管在遠程服務器上本地發出相同的請求時，盡管它的行為與實際情況一樣，但性能還是不錯的。 CPU /網絡等的值也很低。
• 網絡問題（帶寬，路由器，防火牆，負載平衡器）：可能但不太可能，因為其他所有東西都運行穩定並且我們的托管服務商也參與了分析。
• 線程池飢餓：不是不可能，而是理論上的-確保我們有很多異步調用，但是在此問題上是否有幫助？
• HttpCompletionOption.ResponseHeadersRead：本身不是問題，但也許是一個難題？

到目前為止，最好的解釋集中在ConnectionLimit上：我們僅在最近才開始設置上述值，這似乎已經引發了問題。 但是為什么呢？ 重用連接而不是為每個請求打開一個新連接不是一種改進嗎？ 我們設定的值似乎比較保守嗎？

我們最近開始嘗試使用這些值，以查看它們對生產的影響。 然而，我們仍然不清楚這是否是唯一原因。 我們希望能有一種更直接的分析方法。 不幸的是，內存轉儲和netstat打印輸出無濟於事。

我們將高度贊賞有關如何分析或提示可能原因的一些建議。

*****編輯*****

將連接限制設置為1000可解決此問題！ 所以問題仍然是為什么呢？ 據我們所知，默認連接限制在非Web中為2，在Web應用程序中為1000。 MS建議使用CPU * 12的默認值（但他們沒有實現該默認值？！），因此我們的更改基本上是從1000更改為48。仍然可以看到只有少數幾個連接是打開的。 有誰能對此有所啟發？ 打開新連接，重用現有連接，流水線等的確切行為是什么？ 是否有任何信息來源？

Answer 1

ConnectionLimit表示ServicePointManager.DefaultConnectionLimit嗎？ 是的，這很重要。 當值為X時，如果已經有X個請求在等待響應，則在完成任何先前的請求之前，不會發送新請求。

Answer 2

我在這里發布了后續問題： 如何禁用.NET HttpClient的流水線

不幸的是，我的任何問題都沒有真正的答案。 我們最終將ConnectionLimit保留為1000（這僅是一種解決方法，但是我們能夠找到的唯一解決方案）。