了解 SignalR、Azure 和消息传递费用

Question

我有一个 blazor 服务器端应用程序，它非常小并且仍在开发中。目前只有我自己和一名用户测试该应用程序的预生产。

即使 Web 应用程序托管在 Azure 中，我们也使用 SignalR 将内部打印同步到本地应用程序。今天，我们遇到了 SignalR 的问题，因为我们达到了 24 小时内发送 20,000 条消息的免费套餐限制。这让我很困惑，因为它不是一个聊天应用程序或任何密集型的应用程序。我们每隔 5-10 分钟左右单击一个按钮，它就会向 SignalR 中心发送一条消息。

经过仔细检查，很明显我没有正确处理集线器，因此连接保持打开状态。 （该组件是较大页面的一部分）

添加：

@implements IAsyncDisposable

和

public async ValueTask DisposeAsync()
{
    if (hubConnection is not null)
    {
        await hubConnection.DisposeAsync();
    }
}

现在，当我们离开页面时，可以正确处理集线器。

但是，查看 Azure 日志，消息计数似乎很高。按照此过程，创建了 200（！）条消息：

1. 加载嵌入组件的页面
2. 按两次发送按钮
3. 离开页面

发送按钮只是将消息发送到集线器：

private async Task OnDeliveryNotePrint()
{
    // We only want to print if the order is saved.
    if (dbContext?.Entry(order!).State == EntityState.Unchanged && order != null && hubConnection != null)
    {
        await hubConnection.SendAsync("SendPrintJob", new PrintJob { TimeRequested = DateTime.Now, PrintJobType = PrintJobType.DeliveryNote, PrintJobId = order.Id });
        toastService.ShowInfo("Print job sent to the server.");
    }
    else
    {
        toastService.ShowWarning("Please save changes before printing.");
    }
}

好吧，我的理解可能不太好，但是这个过程是如何创建 200 个 SignalR 消息的呢？我已阅读文档中的故障排除页面，但找不到任何可以向我展示如何更好地理解这里发生的情况的内容。

这也是我了解到我没有正确处理连接的地方，并且在一定程度上修复已经起作用，因为消息计数已显着下降，但上述场景的 200 条消息仍然感觉有点丰富。

免费套餐（我认为我们很容易访问）的消息限制是 20,000 条。按照消息发送的速度，情况不会如此，而且我们认为影响很小的事情的成本很快就会增加。

我是否完全偏离了滑雪道，没有正确理解这个过程，还是我在某个地方出错了？

更新： 我从信号器仪表板中提取了跟踪日志，上面的步骤确实创建了 201 条消息。这些消息绝大多数是通过

componenthub

(199) 发送的，然后我可以通过

printhub

(2) 查看我的消息。对于一个如此依赖信号器的应用程序来说，免费层仅支持 20,000 条消息似乎很奇怪。只需点击应用程序就可以轻松地耗尽它。

经过进一步调查，它看起来类似于 停止 Blazor SignalR 通过 Azure SignalR 和 https://github.com/Azure/azure-signalr/issues/1738

Answer 1

经过我的调查，我们发现大量的消息是由Blazor Server本身的组件、页面和状态之间的通信产生的。 这是设计使然的。

我们可以通过在azure门户中启用Live Trace来监控消息详细信息。