14

When I publish a Blazor Server Side app on Azure, Visual Studio prompts a message that says:

Your application is making use of SignalR. For environments that need to scale we strongly recommend adding a dependency on Azure SignalR Service.

However, my app works just fine as it is, without making use of Azure SignalR Service. So I was wondering if it really makes sense to integrate it or it's just a way for Microsoft to squeeze a few extra dollars from our pockets...

Has anyone tried deploying a Blazor Server Side app with and without Azure SignalR Service, in order to test if there is any actual difference in terms of performance? What kind of advantage should I expect from it?

enter image description here

4

4 回答 4

10

我知道这是一个老问题，但我想添加一些关于成本的有价值的信息。

Azure SignalR 的成本可能会急剧增加。消息大小除以 2k，因此从计费角度来看，一条 10k 条消息将是 5 条消息。

使用免费套餐，您每天最多可获得 20 个并发连接和 20k 条消息，标准层允许每单位 1k 个并发连接和每单位每天 100 万条消息。每个单元每月 49 美元。然后是每百万条消息超过 1 美元。

这可能看起来不多，但我看到一项服务在短短 7 天内累积了价值超过 3,000 美元的 SignalR 服务。

于 2020-10-13T20:58:36.830 回答
10

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

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

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

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

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

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

于 2020-03-12T19:11:13.823 回答
0

Blazor 服务器应用构建在 ASP.NET Core SignalR 之上。每个客户端通过一个或多个称为电路的 SignalR 连接与服务器通信。电路是 Blazor 对 SignalR 连接的抽象，可以容忍临时网络中断。当 Blazor 客户端看到 SignalR 连接断开时，它会尝试使用新的 SignalR 连接重新连接到服务器。

连接到 Blazor 服务器应用的每个浏览器屏幕（浏览器选项卡或 iframe）都使用 SignalR 连接。与典型的服务器渲染应用程序相比，这是另一个重要区别。在服务器渲染的应用程序中，在多个浏览器屏幕中打开同一个应用程序通常不会转化为对服务器的额外资源需求。在 Blazor Server 应用程序中，每个浏览器屏幕都需要单独的电路和单独的组件状态实例以由服务器管理。

每当您需要扩展 SignalR 时，您都需要实现一种称为背板的模式。使用 Azure SignalR 服务，它已经存在，因此您无需自己进行操作。

https://docs.microsoft.com/en-us/aspnet/core/blazor/hosting-models?view=aspnetcore-3.1

于 2020-03-12T18:30:59.377 回答
0

如果您没有真正投入生产或者这是一个宠物项目，只需将 Blazor Hub 配置更新为长池而不是 WebSockets，这样您就不会在控制台中出现错误。

        app.UseEndpoints(endpoints =>
        {
            //...
            endpoints.MapBlazorHub(options =>
            {
                options.Transports = HttpTransportType.LongPolling;
            });
            //...
        });

到目前为止，Azure App Service WebSockets 的免费定价层 F1 是有限的（参考https://docs.microsoft.com/en-us/azure/app-service/faq-app-service-linux#web-sockets）。Ofcource WebSockets 比长池方法好得多，由您决定是否为单独的 Azure 服务 (Azure SignalR) 付费。

于 2021-03-25T15:29:20.233 回答