2 Commits

Author	SHA1	Message	Date
JianFeeeee	2572688c51	proc: 性能基准 + 流式压测（Part 6.6 验收项） ... 此前只做了功能冒烟与内存快照，延迟与压测都没测。这两项是计划里 明确列出的验收条件，补上。 ## 基准结果（AMD Ryzen 7 7840HS） | 项目 | 实测 | 基线 | |---|---|---| | 工具调用 RPC 往返 | 24.1 µs | 实验 11: 19.6 µs（同量级） | | 锁仲裁（内核侧） | 0.76 µs | 见下注 | | 事件环写入 | 95 ns | — | | 事件环并发写入 | 83 ns | 无锁竞争恶化 | | 完整 stage 往返 | 132 µs | 含 3 次进程间往返 | | 共享段编解码 | 3.7 µs | 占 stage 的 2.8% | **锁仲裁 0.76µs 不可与实验 3 的 19.40µs 对照**——测的不是同一个东西： 实验 3 测插件经 RPC 请求锁的完整跨进程往返，本基准只测内核侧 lockRegistry.acquire/release。真实成本仍在 20µs 量级。 基准原名 BenchmarkStageLockRoundTrip 有误导性，已改为 BenchmarkStageLockArbitration，并在注释里写明不可对照的理由—— 否则日后有人拿 0.76µs 去比 19.4µs 会得出「优化了 25 倍」的错误结论。 **stage 往返 132µs 的成本构成**：共享段编解码只占 3.7µs，其余是 一次 stage 要走 3 次进程间往返（stage.invoke + 插件侧反向的 stage.lock / stage.unlock）。相对 LLM 往返 2-8 秒可忽略；要优化的方向是 把 lock/unlock 合入 stage.invoke 的请求/应答，省掉两次往返。 ## 流式压测：§4.3 标记「风险高」的那一项通过 原文担忧：「Bus.Publish 路径禁用任何锁/阻塞——流式输出逐 token 发布， 任何等待都会卡顿」。事件环是 Part 5 新加在这条路径上的，必须验。 ``` 5000 次 Publish + 每条睡 20µs 的慢消费者 实测 2.29ms，均摊 457 ns/token 同步语义理论下限 100ms 订阅者 1 个：1.547ms（515 ns/次） 订阅者 8 个：1.518ms（506 ns/次） ← 无线性恶化 环溢出（无消费者写 30000 次，cap=8192）：均摊 35 ns/次 ← 仍 O(1) ``` 2.29ms 与实验 4 的数字完全一致（那次也是 2.29ms / 0.46µs per token）， post-and-forget 在实现中成立。 第三项的意义：消费者完全停摆时写端覆盖最旧 slot，这条路径仍是 O(1)， 故「消费者卡住」不会连带拖慢内核主循环。 Ref: docs/zh/plugin-migration-plan.md Part 6.6、docs/zh/架构迁移评估.md §4.3	2026-09-02 21:42:18 +08:00
JianFeeeee	1d7f011e5d	plugin: 17 插件全量重编 + 端到端冒烟验证（Part 6.3） ... ## 17 个插件源码零改动，全部重编为 plugin.bin 16 个 × 3 平台（linux/darwin/windows），qq 1 平台（plg.json 自己声明 bundle:false）。luademo 走 Lua 解释器不适用。 git status example/ 无输出 —— 这是「业务代码零改动」的硬证据。 批 3 那些预估高风险的插件（qq 2686 行双向通道、browser 12 工具 + InjectInterruptText、a2a/acp 的 InjectInputSync 同步注入）一次全过， 因为它们只碰公开 SDK 合同面，而合同面在 Part 2 已 51 个 method 全量平移。 唯一一次失败与迁移无关：rss 的 github.com/mmcdole/gofeed 不在本地模块 缓存且 proxy.golang.org 不通，换 GOPROXY=https://goproxy.cn 后通过。 ## 真实 homed 加载验证 15 个外部插件全部经 proc 通道建链（protocol=1 sdk=0.9.2，各自独立 PID）， 31 个插件 loaded（15 外部 + 16 内置）。 ai_image / files 未走 proc 通道：同名内置插件优先（工厂编译期注册）， 外部插件被遮蔽。这是既有行为，与迁移无关。 事件环与共享段均正常创建，且共享段是**一块** 256KB 服务全部 15 个插件。 ## 冒烟测试 4 项（internal/plugins/real_plugin_smoke_test.go） 用真实 example 产物而非 testdata 假插件；manifest 刻意写 "entry":"plugin.so" 验证工具链与内核都已不看 entry 值。未重编时 skip 而非 fail。 - ToolInvokeRoundTrip：工具真实调用往返（此前只验证到"注册"）。 weather_current 返回结构化参数校验错误——这恰是链路通的证据。 - StageRewriteTakesEffect：sanitizer 清洗 ANSI 序列，改写经共享段回到 内核 StageContext - MultiPluginShareOneSegment：sanitizer + weather 并发，清洗结果不被覆盖 - CrashDoesNotKillKernel：SIGKILL 插件进程后 homed 存活、17 插件仍在 （对比 C ABI 下插件 panic 直接带崩 homed，§1.2 现网已发生） ## 开销实测与基线偏差 15 个插件进程 RSS=88.0MB PSS=87.9MB 线程=82，均摊 5.87MB / 5.5 线程。 RSS 88MB vs 实验 5 基线 29.1MB **不是回归，是基线不可比**：实验 5 用 2.68MB 最小插件，真实插件 3.1~14.8MB。可比的结构性指标： - 均摊线程 5.5 vs 4.9 —— 同量级，无线程膨胀 - PSS/RSS 99.9% vs 44% —— **明显差于基线** 第二项是真实发现：基线里 PSS 远低于 RSS 说明 Go runtime 只读代码页在 进程间共享；实测几乎不共享，因为 15 个插件是 15 个不同的二进制，没有 共同物理页可映射。这是「每插件独立二进制」的固有代价，意味着实际内存 开销高于 §4.3 的乐观估计。压这一项的方向是共享 launcher 二进制。 ## 工具脚本入 experiments/19-migration-verify scripts/ 被 .gitignore 排除，故放到已跟踪的 experiments 目录下， 与 01~18 的可复跑实验并列。 measure-plugin-overhead.sh 第一版有统计口径 bug：RSS 读 status 的 VmRSS、 PSS 读 smaps_rollup 的 Pss，输出 PSS(87.9MB) > RSS(69.1MB) —— 物理上不可能。 两者对共享内存段计入方式不同（smaps 的 Rss 含 Pss_Shmem）。已统一从 smaps_rollup 读。另修 bc 不可用导致 MB 全显示 0.0（改用 awk）。 Ref: docs/zh/plugin-migration-plan.md Part 6.3、docs/zh/架构迁移评估.md §4.3	2026-09-02 20:20:25 +08:00