Azure Web App 中的 SignalR 连接限制

Question

我在我的一个 ASP.NET Core MVC 应用程序 (.NET 6) 中使用 ASP.NET Core SignalR，它作为 Web 应用程序托管在 Azure 上。

在 SignalR 无法接受更多连接之前，我正在努力查找有关我的 Web 应用程序可以处理多少并发连接的信息。

我知道 Azure 提供付费的 Azure SignalR 服务，从 1000 个并发连接开始计费。 这是否表明我的设置最多只能使用 1000 个连接？ 到目前为止，400 个并发连接已经完美运行。

Answer 1

这里有一些变量在起作用，所以没有人可以告诉您“在自托管 SignalR 解决方案中的 X 连接以上，您需要使用 SignalR 服务。” 根据您的解决方案的配置方式，一个或另一个组件可能是限制因素。

例如，应用服务服务限制显示每个 Web 应用实例的最大 Web 套接字数。 对于基本层，它是 350。当您需要 351 时，您的选择是：

• 将您的应用服务计划扩展到标准或更高版本。
• 添加其他实例并使用 Redis 或服务总线背板。
• 使用 SignalR 服务。
• 禁用 SignalR 的 websockets 并依赖诸如长轮询之类的东西，这受服务器资源的限制。

在您转到标准服务层并横向扩展至多个 Web 应用程序实例后，您可以自己托管 SignalR。 我们已经通过四个标准 S3 实例以这种方式运行了超过 5000 个并发连接的客户端。 四是一个误导性的数字，因为我们需要为应用程序的其他部分提供马力，而不仅仅是 SignalR。

当你自己托管 SignalR 时，它会施加一些限制，并且有各种创造性的方式可以让你自己上吊。 例如，使用 SignalR netcore，您需要具有用于多实例环境的 ARR 亲和性令牌。 太糟糕了。 我曾经在从前端关闭连接后实施紧密轮询重新连接。 当我们的服务器宕机超过两分钟后又恢复了，这很有趣，我们有几千个网络浏览器紧密轮询试图重新连接。 在标准层 Web 应用程序中，很难掌握多个 websocket 连接消耗的内存和 CPU 百分比。

所以说完这一切，答案是“这取决于很多事情”。 两种方式都完成后，我会继续使用 SignalR 服务。

Answer 2

• 根据官方文档， default每个单元的Concurrent Connections数和maximum limit如下所示，

• 在 Azure 门户中，我们有一个Pricing tier ， Features似乎是最大限制，我们有一个功能 - Autoscale ，如下面的屏幕截图所示。

• 据我所知，根据 Azure 门户，我们不能超过 1000 个连接，但如果你想要更多，你可以提出 Azure功能请求以及支持票。

Answer 3

首先，我认为尝试计算 azure app service 的限制并发连接数是不对的。 你使用了 asp.net core Signalr 并将应用程序发布到 azure app 服务，而不使用 Azure Signalr 服务。 所以限制是基于 azure app service 。 而且我们还知道 asp.net core Signalr 使用 websocket 连接，因此我们应该检查应用服务定价层的Web sockets per instance值。 但是，还有一些其他配置：

如果将基本层中的应用程序扩展到两个实例，则两个实例中的每个实例都有 350 个并发连接。 对于标准层及以上，网络套接字没有理论上的限制，但其他因素可能会限制网络套接字的数量。 例如，允许的最大并发请求数（由 maxConcurrentRequestsPerCpu 定义）为：每个小型 VM 7,500、每个中型 VM 15,000（7,500 x 2 核）和每个大型 VM（18,750 x 4 核）75,000。

如果您的应用服务中有其他 azure web 应用，它也会影响连接限制，这就是为什么我们总是建议将 Signalr 应用放在单独的应用服务/服务器中。

顺便说一句，即使我们可以计算出一个确定的连接限制数量，我们也不能忽略带宽限制，只是想象每个信号器消息的大小为 1Mb。

另一点，在本节中：

使用 SignalR 的应用程序需要跟踪其所有连接，这会给服务器场带来问题。 添加一个服务器，它会获得其他服务器不知道的新连接。 例如，下图中每台服务器上的 SignalR 不知道其他服务器上的连接。 当其中一台服务器上的 SignalR 想要向所有客户端发送消息时，该消息只会发送到连接到该服务器的客户端。

因此，当您选择将 .net 6 Signalr 应用程序发布到 Azure Web 应用程序时，始终建议使用 Azure Signalr 服务，除非您的连接数一直都很小，消息大小不是“大”，而且您的定价层相对高。 否则，即使连接数没有达到限制，您的应用也可能会遇到带宽性能问题。