Azure上Blazor Server App大量SignalR消息异常问题咨询

核心结论 #

这种900+的SignalR消息量不是预期的最优行为，本质是未优化的列表渲染导致Blazor生成大量细粒度差分更新消息，而Azure SignalR Service的统计方式会把这些差分消息单独计数，放大了感知。

原因拆解 #

1. 列表渲染的细粒度消息：Blazor Server通过SignalR传递UI差分更新，当用普通for循环渲染926个列表项时，每个项的渲染/更新都会生成独立的SignalR消息。初始加载和清除筛选后全量展示列表时，就会产生与列表项数量接近的消息数，这就是Azure指标显示900+消息的原因。
2. 部署方式的统计差异：
   • 连接Azure SignalR Service时，服务会中转并统计每一条Blazor差分消息，所以消息数指标会精准反映细粒度更新的数量。
   • 直接部署在Azure App Service（不额外配置SignalR服务）时，用的是App Service内置的WebSocket支持，Azure的指标会按带宽统计而非单个消息计数，看似没有消息数限制，但实际传递的消息总量和前者一致，只是统计维度不同。
3. 浏览器工具与Azure指标的差异：浏览器WebSocket工具看到的27条消息是合并后的WebSocket帧，一个帧可能包含多条Blazor差分消息；而Azure SignalR Service会拆分统计每一条Blazor消息，所以两者计数差异巨大。空白消息确实是SignalR的保活心跳包，属于正常机制。

优化方案 #

1. 核心优化：使用虚拟化列表 #

替换普通for循环为Blazor内置的Virtualize组件，它只会渲染可视区域内的列表项，大幅减少初始渲染和全量更新时的消息数：

@page "/item-list"

<input @bind="filterText" placeholder="筛选..." />

<Virtualize Items="@filteredItems" Context="item" ItemSize="50">
    <div @key="item.Id">@item.Name</div>
</Virtualize>

@code {
    private string filterText = "";
    private List<Item> allItems = new();
    private IEnumerable<Item> filteredItems => allItems.Where(i => i.Name.Contains(filterText, StringComparison.OrdinalIgnoreCase));

    protected override async Task OnInitializedAsync()
    {
        allItems = await FetchItemsFromApi();
    }

    private async Task<List<Item>> FetchItemsFromApi()
    {
        // 单次API调用获取数据
        return await Http.GetFromJsonAsync<List<Item>>("/api/items");
    }
}

2. 辅助优化：减少不必要的消息 #

• 给列表项添加@key指令：确保Blazor能正确复用DOM元素，避免不必要的重建和消息发送，比如示例中的@key="item.Id"。
• 合并子组件：如果每个列表项是独立的子组件，尽量改为内联元素或减少子组件拆分，因为每个子组件的状态变化都会生成独立的SignalR消息。

3. 部署方式选择 #

• 如果应用需要支撑大规模并发连接（数千以上用户），Azure SignalR Service是必要的，它能横向扩展SignalR连接能力，避免App Service的连接数限制。
• 如果用户量不大，直接使用App Service内置的WebSocket即可，无需额外配置Azure SignalR Service，减少中转环节的开销。

内容的提问来源于stack exchange，提问作者Rob Higginbotham