2 Commits

Author	SHA1	Message	Date
JianFeeeee	20e5d917c3	chore(stress): 加 waiter 远程更新脚本；修 cmp.py 的 docstring 格式 ... ## deploy-waiter.sh：106 / 30 的 waiter 更新 现状（更新前）：两台都是 8月27日构建的 /opt/waiter/waiter（11,388,177 字节）， 以 root 跑 waiter-remote.service，配置指向 ws://192.168.2.60:9890/… 安全设计： - 先备份旧二进制（`$BIN.bak-<时间戳>`），失败即回滚（脚本内自动） - **只换二进制，不动 waiter.yaml**（配置由 deploy 后单独追加） - **逐台更新并验证，不并行** —— 两台都连同一网关，同时重启会同时断链 - 106 走 admin+sudo、30 走 root - 验证项：服务 active + 进程时长 + **配置 md5 未变** 用法：`check`（只读）/ `deploy <ip>`（需输 yes）/ `rollback <ip>` ## cmp.py：两处格式 docstring 的 `"""` 紧贴内容、以及函数段之间缺两个空行（PEP8）。纯格式， 无逻辑改动。	2026-09-27 19:42:06 +08:00
JianFeeeee	190e46908d	test(stress): 补更新前后全面对比脚本（cmp.py），修 blast 的计数错误 ... ## cmp.py：更新前后对比的四个维度 ★ 每轮都记录**处理数**（响应里有多少个工具结果标记）与**是否出现 error 帧**， 任一不符即记失败。理由：工具调用这一路的失败模式几乎都是**静默**的 —— 工具没跑、参数混拼、只处理了第一个 tool_call，都不报错只是结果不对。 "跑完没崩"完全不能说明它 work。 1. **批内工具调用**：!slowbatchN 在两版上各跑几轮，比中位耗时与处理数 2. **并发 vs 强制串行**（新版内部对照）：!slowbatchN vs !serialbatchN 3. **调度器并发轰炸**：多连接并发排队，算通过率 4. **连续稳定性**：20 轮无错误率 ## 修掉 mock 的 !serialbatch 缺失 之前只在 /tmp 的临时副本里加过，没进仓库，导致 cmp.py 测「强制串行」时 那个 marker 根本不存在 —— 测出来的"串行"其实是并发，**加速比是假的** （0.34x / 0.31x，看起来并发比串行慢）。已加回并说明它的用途：跨版本做不了 并发/串行对照（旧版适配器缺 stream_index，工具一个都没真跑），只能在 同一套内核上做。 ## 修掉 blast 的计数错误 第一版按 `conns * inputs` 起线程、每个线程又跑 `inputs` 轮 ⇒ 总输入数是 conns×inputs²，分子分母量纲不一致，算出过 **"128/32 = 400%"** 这种荒谬数字。 现在：恰好 conns 个 worker、每个跑 inputs 轮；且分母用**实际发出的**输入数 （含连接失败的），否则连接失败时通过率会虚高。 ## 踩过的两个坑（都写进注释） - 内核 `task.go:353` 有输入去重（`isDuplicateInput`，为 webui 断线重连重放 而设），相同文本被丢弃并回空响应 ⇒ 每轮输入必须带唯一后缀 - cli 的 auth 帧本身就是 `{"type":"response"}` ⇒ 必须先吃掉它再开始收集， 否则第一轮的"终止帧"是 auth，测出来耗时恒为 0	2026-09-27 18:56:25 +08:00