在 kestrel 中自行托管的信号器中的最大并发请求数

Question

我开发的应用程序遇到了一个奇怪的问题。该应用程序是托管在 Kestrel 上运行的 AspNetCore 2.0 的 Windows 服务。此应用程序通过充当代理的 IIS 站点接收请求。

在这个应用程序中，我还使用了使用 Microsoft.AspNetCore.Owin 集成的信号 2.2.2。一切正常，直到我检测到应用程序没有响应请求。

同一台机器上的其他应用程序使用相同的 IIS 服务器作为代理工作正常。重新启动为站点服务的应用程序池暂时解决了问题。

当同一台机器上有 400 个 signalr SSE 连接时，问题再次浮出水面，并通过监控信息挖掘应用程序似乎挂起。这似乎是合理的，因为我发现默认情况下 OWIN 将并发请求的数量限制为100 * number of cpus。（请注意，同一台机器上的站点每分钟可以毫不费力地处理 5000 个请求，但这些请求不像 SignalR 那样是长期存在的请求）

问题是，在 AspNetCore 中托管 Owin 时，我似乎无法找到相同的选项。有人知道这是否可以成为解决方案以及正确的设置是什么？

编辑：我相当肯定这个问题是由同时打开的 SignalR 连接数引起的，因为通过在 Javascript 中禁用它，问题就消失了。

第二次编辑：signalr 似乎不是杯具，因为在测试和生产中使用曲柄对站点进行负载测试一直工作到 5000 个并发连接，这是默认的 IIS 限制，对我来说很好

Answer 1

经过一番尝试和错误后，我已经能够识别并纠正问题，但这并不是一件容易的事，所以如果其他人偶然发现同样的问题，我将留下这个答案。

禁用 SignalR 并不能解决问题，但可以减少该问题的出现。

由于服务器和 IIS 上的监控，我观察到当站点的连接数量开始快速增长时，问题就出现了。该系统主要向其他服务发出请求，因此它没有数据库，也没有昂贵的计算。

检查代码发现存在三个问题：

• 为每个请求创建一个新的 HttpClient，这会耗尽请求之间未重用的套接字blog blog2 blog3
• 默认情况下，httpClient 上到单个域的最大并发连接数，此限制默认设置为 2 (!!!) blog4
• 该代码同步等待对另一个系统的每个 Web 请求（该程序是从从未显示此问题的 mvc4 站点移植的）。这在 MVC 中工作得很好，但 ASP.NET Core 对此非常敏感，因为它将快速耗尽所有可用线程，并且因为线程池以核心数量开始，它们将很快耗尽，从而使所有请求等待。可以使用ThreadPool.SetMaxThreads(Int32, Int32)增加此值作为临时解决方案，但唯一的解决方案是转换异步调用中的所有调用。

一旦所有调用都是异步的，问题就不会再出现。基本上，这个问题是由于线程池饥饿和 aspnet 核心对它与 MVC 的敏感性造成的。在这里您可以找到一个很好的解释和使用 PerfView 的检测方法。