Bug 报告：Web 界面卡顿——后台会话高速输出时新建会话等交互延迟数秒（mux 事件流无订阅过滤、无背压）

[hiro-nikaitou]

一句话问题

后台多个会话并行输出时，mux 全量事件流（实测 344 帧/s、约 1.1MB/s）淹没浏览器主线程，点击"新建会话"等 UI 交互延迟数秒。

复现步骤

1. 同时运行多个会话（含 subagent）并保持模型输出（实测 3 个会话并行、token 以约 2ms/chunk 流出，持续数十分钟）
2. 打开 Web UI（localhost:3080），页面保持前台
3. 点击侧栏"新建会话"按钮，观察界面切换耗时

实际结果

• 安静时点击"新建会话"到新会话视图出现约 900ms；事件爆发时延迟至数秒，期间界面无响应
• events.mux WebSocket 实测：5 秒采样 2755 帧（344 帧/s、1.1MB/s），以 session/event（assistant/chunk 逐 token）为主，另有约 40 帧/s 的 session/projection
• 浏览器主线程被消息处理与 React 渲染占满；Host 进程内存随事件流增长（实测约 1.2GB）
• 后端本身不慢：session.create RPC 实测约 195ms

预期结果

• 新建会话等前台交互应 <300ms
• 后台会话（尤其是未在页面中打开的会话）输出不应影响前台交互

环境

• DSH 0.1.0-rc.6（dsh web，Windows 11，Chrome/Edge localhost）

根因分析（代码定位）

• packages/host/apiproxy/src/api-proxy.ts 的 events.mux handler：每个连接注册全局 session/event 监听，所有会话的所有事件全量广播给所有浏览器连接，无按会话订阅过滤
• FrameQueue（同文件）：无界、无背压，慢消费者使队列在 Host 内无限膨胀
• assistant/chunk 事件粒度为单个 token（约 2ms 一条），无合并/节流
• 浏览器端 session/projection 帧对所有会话触发列表 markDirty 重渲染（侧栏列表、标题等）

建议修复

1. mux 广播按会话订阅过滤：session/subscribed 机制已存在，广播时按每个连接的订阅集合过滤即可
2. token chunk 合并/节流：按 50-100ms 批量推送，可将 344 帧/s 降到约 20 帧/s
3. FrameQueue 有界 + 慢消费者策略（背压或丢弃策略），防止 Host 内存膨胀

验收条件

• 多会话并行高速输出时，点击新建会话/切换会话的交互延迟 <500ms
• Host 内存不随持续事件流无限增长

[NOirBRight]

补充一组本地 Web UI 实测，现象和本帖以及 #1262、#3275 一致。

现象

卡顿时静态 HTTP 仍然正常，大约 1–5ms。问题不在端口或普通请求，而在会话事件流：

• dsh web 进程 CPU 约 60–188%，RSS 从约 2.2GiB 涨到 3.5GiB
• Chrome renderer 约 100–146% CPU、约 1GiB 内存
• 单条 WebSocket 已发送约 97.5MB，服务端 send backlog 约 2.35MB
• 连接约 99.5% 时间处于客户端接收窗口限制
• 旧 service cgroup 峰值约 12.9GiB 内存、299MiB swap；约 21 分钟墙钟时间消耗约 51 分钟 CPU

多会话同时高速输出时复现。重启后积压会清零，但并发输出继续时很快再涨。

代码路径

当前发布版里：

• events.mux 把所有 session 的事件（含 assistant/chunk）推给每个浏览器连接
• Host FrameQueue.buffer 没有上限
• 浏览器 WebSocket inbox 也没有上限
• 慢消费者没有断线、丢帧或重新同步

于是形成：多会话输出 → renderer 处理不过来 → WebSocket 堵塞 → Host 队列堆积 → Node 分配/GC 加剧 → 前后端同时满核。

插件侧说明

第三方插件里的全局 MutationObserver 会把浏览器更快变成慢消费者，从而放大卡顿。但即便卸掉这些插件，Core 的全量 mux、无上限 FrameQueue 和无上限 inbox 仍是独立根因。只修插件可以推迟卡顿，不能根治内存增长。

建议

• 给 mux / FrameQueue 加高水位，并对慢消费者断开或重建
• 按 session 订阅，而不是把所有会话事件广播给每个浏览器连接
• 对 assistant/chunk / tool 输出做合并或允许重同步
• 暴露队列长度和发送速率指标，便于确认背压是否生效

我们这边不会提 Core PR，只在这里报告。

[NOirBRight]

补充一组本地复现数据，结论与本帖以及 #1262、#3275 一致。

现象

静态 HTTP 仍然正常（约 1–5ms），但 Web UI 交互卡死。卡顿时：

• dsh web 进程 CPU 约 60–188%，RSS 从约 2.2GiB 涨到 3.5GiB
• 浏览器 renderer 约 100–146% CPU、约 1GiB 内存
• 单条 WebSocket 已发送约 97.5MB，服务端 send backlog 约 2.35MB
• 连接约 99.5% 时间处于客户端接收窗口限制
• 旧 service cgroup 峰值约 12.9GiB 内存、299MiB swap；约 21 分钟墙钟时间消耗约 51 分钟 CPU

多个会话同时流式输出时复现；重启进程后积压会清零，但并发输出继续时会再涨。

根因（Core，独立于插件）

即便不加载第三方插件，当前 Host 仍然：

• events.mux 把所有 session 的事件（含 assistant/chunk、tool-call-chunks）推给每个浏览器连接
• Host FrameQueue.buffer 无上限
• 浏览器 WebSocket inbox 无上限
• 慢消费者没有断线、丢帧或重新同步

插件侧的全局 MutationObserver 会把浏览器更快变成慢消费者，从而放大上述队列膨胀，但 全量 mux、无界 FrameQueue、无界 inbox 仍是独立根因。只修插件只能推迟卡顿，不能根治内存增长。

建议

1. 给 mux / FrameQueue 加高水位，并对慢消费者断开或重建
2. 按 session 订阅，而不是把所有会话事件广播给每个 UI 连接
3. 对 assistant/chunk / tool-call-chunks 做合并或重同步，避免逐 token 入队
4. 暴露队列长度、发送速率、backlog 指标，便于确认背压是否生效

[dearbld]

+1 并补充：0.1.5-rc.1（当前 latest）发布产物源码核对——三处根因仍在

本帖描述的三个根因（全量 mux 广播、FrameQueue 无上限、慢消费者无处置），我在当前最新版 0.1.5-rc.1（2026-09-10 发布）的 npm 发布产物里逐行核对，均未修复，证据如下：

1. 全量广播仍在：dsh-host-apiproxy 包的 events.mux handler 注册的是全局 ctx.on("session/event", ...)，对每个已连接客户端无差别推送所有会话的所有事件——没有按 session 的订阅过滤。
2. FrameQueue 仍无上限：FrameQueue 类实现为 buffer = [] + push(item){ this.buffer.push(item); ... }——无高水位、无背压、无丢帧。
3. 慢消费者仍无处置：仅在客户端 abort（断开）时清理队列，积压期间既不踢线也不重同步。

另补充一个相关的活跃源：dsh-agent-loop 对每个模型分片 chunk 都发布一个 type:"chunk" 事件（打字机效果），dsh-session 源码注释自称 session/event firehose——所以在多会话并行流式输出的场景，每个浏览器连接仍会被全量 token 级帧流淹没（与楼主实测 344 帧/s / 1.1MB/s 同构）。

场景影响实测：多窗并行（后台会话高速输出）时，前台 Web UI 的新建会话/切换等交互延迟数秒，与楼主描述一致；重启后恢复，并发输出再起时复发。

想问官方：这三个根因（尤其按 session 订阅过滤 + 发送队列高水位）是否已纳入 0.1.5/0.1.6 的修复计划？如有时间线，大家可以先靠「少开并行输出会话」缓解。谢谢！