perf(concurrency): remove unsupported product admission limits
This commit is contained in:
mesalogo
@@ -67,7 +67,7 @@ Main 负责窗口、生命周期、权限和消息转发。数据库查询、文
|
||||
- 多条更新合并后，每帧最多提交一次；同步到全局状态的频率要更低，目前是 250 ms。
|
||||
- 高频路径上不能读取布局（`getBoundingClientRect`、`scrollHeight` 等），布局读取要集中到每帧一次。
|
||||
- 合并更新不能丢失、重复或打乱顺序。每条数据带序号，并有测试覆盖。
|
||||
- 显示合并与持久化分开。可以合并进度或替换过时刷新，不能静默丢弃消息、工具结果或需确认的事件；多生产者缓冲达到容量时等待或明确失败，不无限增加内存。
|
||||
- 显示合并与持久化分开。可以合并进度或替换过时刷新，不能静默丢弃消息、工具结果或需确认的事件；多生产者缓冲只有在用户设置、外部协议、数据安全或实测故障证据要求时才设置容量，否则将负载交给所属 Host。
|
||||
|
||||
### P4 数据只有一份来源，只传变化部分
|
||||
|
||||
@@ -131,8 +131,8 @@ Main 负责窗口、生命周期、权限和消息转发。数据库查询、文
|
||||
|
||||
- Main 全局控制队列不得等待模型、网络、原生启动或耗时清理。必要登记和状态提交可短暂串行，等待在所属操作范围内完成。
|
||||
- 重查询复用有界 Worker；必要写入不排在整个导入解析或模型请求之后。长事务先减少事务内无关计算，再测写入排队，不把阻塞简单搬进唯一存储队列。
|
||||
- 复用现有池、批处理和队列，记录在途数、排队数及字节上限。有限任务在持续竞争下仍须完成，繁忙会话不能无限抢占下一批；有实测饥饿才引入最小调度调整，不预建通用优先级框架。
|
||||
- 控制和取消不等待新的执行槽位；饱和时按业务语义等待或返回可恢复错误。禁止静默丢失、无限缓冲、无限重启或自动扩增进程。
|
||||
- 复用现有池、批处理和队列，记录在途数、排队数及实际资源使用。只有有明确依据时才设置容量；没有依据时将负载交给所属 Host，不因内部数字拒绝用户工作。有实测饥饿才引入最小调度调整，不预建通用优先级框架。
|
||||
- 控制和取消不等待新的执行槽位；如果外部或用户设置要求排队，按该语义执行。禁止静默丢失、无限重启或自动扩增进程；不能把未经证明的队列上限包装成稳定性。
|
||||
- 每个异步响应携带已有项目／会话／任务／操作归属；迟到响应不得覆盖新选择或新操作。归属检查先于改变共享请求代次、缓存或队列状态。
|
||||
|
||||
### P12 架构完整性与 KISS
|
||||
@@ -175,7 +175,7 @@ Main 负责窗口、生命周期、权限和消息转发。数据库查询、文
|
||||
| P6 | 空配置和真实数据启动有历史测量；当前 C07 尚未完成监督概览、图谱、历史选择和来源正文的完整冷/暖验收。 |
|
||||
| P9 | 已有 lint 和历史回归上限；间接 SQLite 打开、白名单单调收紧、并发指标缺失和 CI/性能环境接入仍待补齐。 |
|
||||
| P10 | 已有局部输入、刷新和项目切换修复；需要在 C01/C02/C06 中继续验证动画、焦点、滚动、草稿和取消语义没有因降载或合并而退化。 |
|
||||
| P11 | 存储请求和运行时路径已有有界容量与按域归属；C02、C04、C05、C06 尚未证明健康 peer 隔离、饱和恢复、队列排空和有限后台任务完成。 |
|
||||
| P11 | 存储请求已移除产品侧 admission 上限并透传给 storage host；运行时仍有若干并发与消息容量数字，需逐项证明属于用户设置、外部协议、数据安全或实测故障约束，否则应删除。C02、C04、C05、C06 尚未证明健康 peer 隔离、故障恢复和队列排空。 |
|
||||
| P12 | 目标边界和 KISS 约束已写入架构文档；S01-S07 已有生产组合，但删除旧直接入口、异常路径和全候选统一验收仍未完成。 |
|
||||
|
||||
2026-10-04 补充：监督回顾的来源初始化和继续前版本校验已移入现有 Worker 入口的独立连接，扫描不持有写锁，清单按 200 条提交，生产失败不回退 Main 同步扫描。最终发布事务仍在 Main；实现与实测边界见[监督者进度](../features/conversation-supervision/progress.md#2026-10-04-回顾初始化阻塞修复)。
|
||||
|
||||
@@ -110,8 +110,9 @@ Promise 返回本身不能证明工作已离开 Main。启动顺序是先完成
|
||||
|
||||
创建临时配置、插件、socket 或 launch 目录的函数承担创建失败清理。删除前关闭拥有
|
||||
文件或目录的 child、ledger 和句柄，并确认 child 已退出；无法确认时保留材料和 owner
|
||||
metadata，等待后续有界回收。应用临时文件使用仓库根目录 `temp/<task>/`，远程 Host
|
||||
使用专用 `/root/tmp` 子目录。不要扫描或删除用户 Temp、未知归属目录或仅凭名称和年龄
|
||||
metadata，等待后续有界回收。Agent 和测试产生的验证文件使用仓库根目录 `temp/<task>/`；
|
||||
产品运行时临时资源继续使用各自 owner 管理的运行时路径，不能因为位于仓库 `temp/` 就获得删除权。
|
||||
远程 Host 使用专用 `/root/tmp` 子目录。不要扫描或删除用户 Temp、未知归属目录或仅凭名称和年龄
|
||||
判断为过期的资源。
|
||||
|
||||
持久化目录可以位于 `temp/` 下，位置本身不能授权删除。删除前先检查 attachment、
|
||||
@@ -122,14 +123,15 @@ document result、history、branch 或其他 durable reference；释放一个调
|
||||
|
||||
数值只引用[性能原则](../architecture/performance-principles.md)，负载和证据只引用
|
||||
[并发验收](../quality/concurrent-desktop-acceptance.md)。当前 storage client 的请求、
|
||||
读写 pending 和 32 MiB admission budget 是实现约束；paged output 的 8 MiB capture、
|
||||
读写 pending 不设置产品侧 admission 上限，负载透传给 storage host；paged output 的 8 MiB capture、
|
||||
每 writer 1,024 个 pending chunks、4,096 个 active/retained handles 和 64 KiB backing
|
||||
write 也必须服从当前实现与测试。修改前先确认代码中的常量和适用范围，不在本文件复制
|
||||
一套新数字。
|
||||
|
||||
容量应同时约束操作数和字节数。读 worker、写 owner、输出 backing、模型池和 UI 刷新各自
|
||||
使用现有有限机制；队列满时等待或返回可恢复的 busy/capacity 错误。禁止静默丢事件、
|
||||
无限重启、按项目预建服务、为每个调用新增 scheduler，或用串行夹具掩盖饱和。
|
||||
只有用户明确配置、外部协议要求、数据结构安全，或已有实测证明不限制会导致崩溃、
|
||||
数据损坏或不可恢复失败时，才设置上限。读写请求默认透传给所属 Host；不能用内部
|
||||
并发数、队列长度或容量数字替用户决定吞吐。仍禁止静默丢事件、无限重启、按项目预建
|
||||
服务、为每个调用新增 scheduler，或用串行夹具掩盖真实负载。
|
||||
|
||||
## 测试与真实验证
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@
|
||||
|
||||
## 固定负载
|
||||
|
||||
以下为验收档位，不是已验证的容量承诺，也不改变产品并发限制。当前产品若不能达到某档位，记录原因并保留未满足项。
|
||||
以下为验收档位，不是已验证的容量承诺，也不为产品新增并发限制。当前产品若不能达到某档位，记录实际原因；不能用事先写入的内部上限代替测量。
|
||||
使用本地确定性模型与隔离目录，每个输入、事件和工具结果有稳定标识，能够逐项验证顺序及重放结果。
|
||||
不得用真实提供商的网络速度作为应用性能基准。
|
||||
本地临时库、日志和源码测试产物遵守仓库 [AGENTS 临时文件规则](../../AGENTS.md#local-temporary-files)，
|
||||
|
||||
@@ -273,7 +273,7 @@ p95 已回到约 17 ms，但 Main 尾延迟和完整排空仍未达预算；C01/
|
||||
| C06 5 分钟生命周期 | 两版均通过 | 每轮排空耗时一致；4 轮后堆 18.2 → 17.8 MB；另有候选 30 分钟运行 21 轮全部排空、0 错误，堆每轮约增 0.3 MB，与每轮新增 8 条持久化会话一致，结束时驱动退出出错，未记为通过 |
|
||||
| C07 冷／暖进入 | 无持久化来源，来源正文未测 | 冷进入各阶段 1–7 ms，两版一致；暖返回监督概览 38–45 → 25–38 ms |
|
||||
|
||||
产品子任务调度上限为 3，16 个子任务按设计排队，因此“同时运行子任务”门槛按 `min(负载, 3)` 判定。夹具修正：排空等待改为 180 s（两版相同）、子任务按 `childTaskId` 统计、输入框焦点未就绪时重试输入。
|
||||
旧版记录曾按产品子任务并发 3 判定 16 个子任务的测量；该数字没有用户设置或故障测量依据，已从生产默认配置移除。后续验收按实际 offered load 和实际运行数记录，不再用内部上限替代吞吐结果。夹具修正：排空等待改为 180 s（两版相同）、子任务按 `childTaskId` 统计、输入框焦点未就绪时重试输入。
|
||||
|
||||
结论：**正确性门槛在 C01／C02／C04／C06 两版都通过，候选在单会话和并发场景均未退化，Main 尾延迟有改善。** 剩余未满足项：C03 回顾发布与 C07 来源正文需要先有持久化回顾数据的夹具；C05 存储故障注入只有真实 Electron 存储夹具中的进程丢失、发送失败、取消覆盖，未做 App 级故障矩阵。输入 p95 约 8–9 ms，帧 p95 多数 8.5 ms，部分轮出现 16.5／58 ms，两版相同，记为目标差距。
|
||||
|
||||
@@ -304,3 +304,19 @@ portable 新副本（`--fresh`）当前源码复验通过：Assistant 库 175
|
||||
本节合计观察到 **11 次** 外部模型 HTTP 请求：监督存储 4 次、监督审核 2 次、取消 3 次、输出分页失败尝试 2 次。没有重试被计入，也没有远程或 OpenCode／Continue 本地请求。监督链使用的运行时设置仅在隔离进程内解密，原设置字节保持不变。
|
||||
|
||||
验证结束后，隔离数据库、Electron profile、临时工作区、凭据副本、计数 relay 和生成的 probe 目录均已删除；进程检查没有发现属于这些运行的残留进程。该结果证明了当前源码的生产存储监督与直连取消路径，以及一次明确失败的真实模型工具分页尝试；不证明本地 OpenCode、Continue、远程 Linux Host、真实模型工具分页成功、完整桌面 UI、portable 数据副本或 C01–C07／A01–A10 验收已经完成。
|
||||
|
||||
## 2026-10-07 C03／C07 继续验收（当前 HEAD 1f85d0c0）
|
||||
|
||||
本次只修改了 `tests/support/app-perf-concurrent.mjs`、`tests/support/app-perf-driver.mjs` 和 `build/run-app-perf.cjs` 的验收夹具。运行目录为 `temp/goodbuddy-acceptance-continue/`，使用 `npm run build:bundle` 生成当前源码开发构建；每次运行都由 `build/run-app-perf.cjs` 启动隔离 Electron profile、存储 utility process 和 127.0.0.1 回环确定性模型。模型请求总数分别保留在原始 JSON 中，均为回环请求，未发送外部模型请求。
|
||||
|
||||
### C03 混合存储
|
||||
|
||||
命令为 `GB_PERF_MODE=C03 node build/run-app-perf.cjs`，最终证据为 `temp/goodbuddy-acceptance-continue/C03-final4/result.json`。夹具先通过生产 `conversations.saveLocal` IPC 保存 99 个会话、每个 20 条消息，再通过生产 `knowledge.createLibrary` 和 `knowledge.importPaths` 导入知识源；监督页通过真实导航和“回顾”按钮启动生产 `supervision.run`，确定性模型走生产 Runtime 流式接口。回顾提交完成后，结果通过生产 overview、activity 和 batches IPC 读取，首批分页返回的每组证据数为 20，提交进度为 100 批。
|
||||
|
||||
生产重叠窗口包含 100 次历史读取、100 次 Knowledge search 和 100 次监督 overview，Knowledge 导入耗时 7,190.102 ms，重叠窗口 6,701.095 ms。结果 `status=measured`，运行器最终状态为 `passed`；没有使用直接 SQL 写入或预置 review 表。C03 的通过条件仅断言回顾结果存在、100 批提交、抽取分页每批 20 条证据、导入已执行以及三类生产读取各 100 次并发生在导入窗口内。
|
||||
|
||||
### C07 冷热进入
|
||||
|
||||
命令为 `GB_PERF_MODE=C07 node build/run-app-perf.cjs`，最终证据为 `temp/goodbuddy-acceptance-continue/C07-passed/result.json`。冷进入和暖返回分别测量输入框、历史、监督概览、图谱和 Knowledge snapshot 的可用时刻；随后通过生产监督页触发一次确定性回顾，刷新监督页并打开图谱事件。夹具点击真实图谱事件的来源链接，等待 `.supervisor-workspace__source pre` 出现并读取其 DOM 文本长度；本次 `textLength=51`、`rendered=true`，因此来源正文是 UI 内容可用证据，不是 API 返回时间的替代。
|
||||
|
||||
两次运行均为 Windows x64、Electron 44.5.1、当前源码 dirty worktree，外部模型请求为 0。C03／C07 的测量状态通过；其余并发矩阵、三轮交替对照、C05 故障注入、完整预算判定和 A01–A10 仍按上文状态保留未完成，不能由本节扩展为 PERF-15／PERF-16 全项通过。
|
||||
|
||||
Reference in New Issue
Block a user