SignalR SendAsync客户端繁忙时疑似阻塞执行的问题分析与优化

原因解析 #

你的推测是正确的：服务器不会等待客户端处理完回调，但客户端的同步耗时操作会阻塞SignalR的消息接收流程，间接导致服务器发送耗时增加。

具体来说：

• SignalR基于TCP流（WebSocket是TCP之上的协议），数据传输是有序且依赖接收方确认的。当客户端在回调中执行同步耗时操作时，会占用JS的事件循环（或客户端接收线程），导致客户端无法及时处理新的接收数据、发送TCP确认包。
• 首次循环耗时仍为180ms，是因为此时客户端还未被预处理逻辑占用，能及时响应服务器的发送请求；后续循环中，客户端事件循环被阻塞，服务器的发送操作会因为TCP窗口耗尽或SignalR的消息确认延迟而等待，最终拉长了服务器端的发送耗时（但不是180+70，因为等待的是接收确认而非客户端处理完成）。

优化方案 #

1. 客户端异步处理耗时逻辑 #

将预处理操作从SignalR的回调主线程中剥离，避免阻塞消息接收流程：

this.hub.addListener('SendImage', (data: Uint8Array) => {
  // 立即让出事件循环，不阻塞SignalR接收
  setTimeout(() => {
    const startTime = performance.now();
    // 执行耗时的预处理操作
    const readElapsed = performance.now() - startTime;
    this.readTime = readElapsed.toFixed(2);
  }, 0);
});

或者使用Promise实现异步：

this.hub.addListener('SendImage', async (data: Uint8Array) => {
  // 将耗时操作封装为异步任务，不阻塞接收线程
  await new Promise(resolve => {
    const startTime = performance.now();
    // 耗时预处理逻辑
    const readElapsed = performance.now() - startTime;
    this.readTime = readElapsed.toFixed(2);
    resolve(null);
  });
});

2. 优化数据传输体积 #

如果图片数据本身较大，可进一步压缩后发送：

• 服务器端将原始图片转为压缩格式（如JPEG/PNG）后再序列化发送，减少单次传输的数据量。
• 确认MessagePack序列化已启用（你已使用），它比JSON序列化的体积更小。

3. 调整SignalR传输配置（可选） #

• 若使用WebSocket传输，可尝试开启消息分段（SignalR默认支持），将大消息拆分为小片段发送，降低单次传输的压力。
• 服务器端调整HubOptions中的MaximumReceiveMessageSize等参数，避免因消息过大导致的传输阻塞。

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