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 服務，除非您的連接數一直都很小，消息大小不是“大”，而且您的定價層相對高。 否則，即使連接數沒有達到限制，您的應用也可能會遇到帶寬性能問題。