我们有一个 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。我们仍然可以看到只有少数连接是开放的。有没有人可以对此有所了解？打开新连接、重用现有连接、流水线等的确切行为是什么？这有什么信息来源吗？
ConnectionLimit表示 ServicePointManager.DefaultConnectionLimit？是的，这很重要。当值为 X 时，如果已经有 X 个请求等待响应，则在完成任何先前的请求之前，不会发送新请求。
我在这里发布了一个后续问题：如何禁用.NET HttpClient的流水线
不幸的是，我的任何问题都没有真正的答案。我们最终将 ConnectionLimit 保留在 1000(这只是一种解决方法，但我们能找到的唯一解决方案(。