为什么在部署Blazor服务器端应用程序时建议使用Azure SignalR服务? [英] Why is Azure SignalR Service recommended when deploying a Blazor Server Side app?

问题描述

当我在Azure上发布Blazor服务器端应用程序时，Visual Studio会提示以下消息:

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

您的应用程序正在使用SignalR.对于需要扩展的环境，我们强烈建议添加对Azure SignalR服务的依赖.

但是，我的应用程序可以正常使用，而无需使用Azure SignalR服务.因此，我想知道整合它是否真的有意义，或者这只是微软从我们的口袋中掏出几美元的一种方式...

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...

是否有人尝试部署带有和不带有Azure SignalR服务的Blazor服务器端应用程序，以测试性能方面是否存在实际差异?我应该从中获得什么样的优势?

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?

推荐答案

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

There are a few variables in play here, so nobody can tell you "Above X clients, you need to use a SignalR service." Depending on how your solution is provisioned, one component or another may be the limiting factor.

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

For example, the App Service service limits show the maximum number of web sockets per Web App instance. For the Basic tier, it's 350. When you need 351, your options are:

• 将您的应用服务计划"扩展到标准"或更高级别.
• 添加其他实例，然后使用Redis或Service Bus背板.
• 使用SignalR服务.
• 从SignalR禁用websocket，并依赖诸如长时间轮询之类的方法，这受服务器资源的限制.

进入标准服务层并扩展到多个Web App实例后，您可以自己托管SignalR.我们已经用这种方式在5K并发连接的客户端上运行了四个Standard S3实例.四个数字是一个令人误解的数字，因为我们需要应用程序其他部分的功能，而不仅仅是SignalR.

After you go to the Standard service tier and scale out to multiple Web App instances, you can get pretty far hosting SignalR yourself. We've run over 5K concurrently connected clients this way with four Standard S3 instances. Four is a misleading number because we needed the horsepower for other portions of our app, not just SignalR.

当您自己托管SignalR时，它受到一些限制，并且您可以通过多种创造性的方式来吊挂自己.例如，使用SignalR netcore，要求您具有用于多实例环境的ARR亲和性令牌.糟透了.从前端关闭连接后，我曾经实施紧密轮询重新连接.当我们的服务器宕机两分钟以上，又重新启动时，这很有趣，并且我们有数千个Web浏览器进行了严格的轮询以尝试重新连接.在标准层Web应用程序中，很难确定多个Websocket连接正在消耗多少内存和CPU.

When hosting SignalR yourself, it imposes some constraints and there are various creative ways you can hang yourself. For example, using SignalR netcore, you're required to have an ARR affinity token for a multi-instance environment. That sucks. And I once implemented tight polling reconnect after a connection was closed from the front end. It was fun when our servers went down for over two minutes, came back up, and we had a few thousand web browsers tight polling trying to reconnect. And in the standard tier Web App, it's really hard to get a handle on just what percentage of memory and CPU multiple websocket connections are consuming.

因此，在说完所有这些之后，答案是这取决于很多事情".完成这两种方式后，我将继续使用SignalR服务.

So after saying all of this, the answer is "it depends on a lot of things." Having done this both ways, I'd go ahead and use SignalR service.

这篇关于为什么在部署Blazor服务器端应用程序时建议使用Azure SignalR服务?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！