mirror of
https://gitcode.com/JianFeeeee/ModelRouter.git
synced 2026-11-07 09:47:23 +00:00
345cbb30d6
## 现象
线上 quota 页面点刷新后卡在「探测中…」，13 秒仍未完成，按钮一直 disabled。
## 实测根因（不是猜测，是量出来的）
单源探测，隔离实例，逐个测：
juziai 16029 ms
beizhi 16021 ms
localzen 2516 ms
frank 2028 ms
sensenova 258 ms
而插件自己写着 `PROBE_BUDGET_MS = 12000`。**修复前**这两个源各耗 **24013 ms**
—— 精确等于 4s 超时 × 2 次重试 × 3 个 adapter。预算形同虚设。
## 原因
`exhausted()` 用的是 `os.clock()`，它返回 **CPU 时间**。探测几乎全耗在网络等待上，
CPU 几乎不动，于是预算永远不触发。
判据 `TestPluginClockDuringNetworkWait` 直接量这件事：
3s blocked on HTTP: os.clock advanced 0.001s, os.time advanced 3s
**001 秒。** 一个用 CPU 时间写的预算，在 I/O 等待下永远不会响。
这个陷阱和「用忙等测锁竞争」是同一个，只是下沉了一层 —— 而且我第一版判据
正是这么写错的：用自旋循环当「网络等待」，结果 os.clock 走了 1.624s / 2s，
看起来 os.clock 跟的是墙钟，差点得出「不是这个原因」的错误结论。必须用真实
HTTP 请求重测才能拿到真相。
代码里两处同样的写法（第 434 和 466 行），一起改掉。
## 改完的效果
串行 20 源（/call/ 逐个） 84391 ms
fanout 20 源（并行） 16022 ms
⇒ 5.27x
单个死上游从 24s 降到 16s（12s 预算 + 收尾）。
## 还没解决的
16 秒仍然偏长，因为它等于**最慢那一个源**的预算。这不是并行失效，是并行
之后墙钟的必然下界。要再往下走只有两条路：把预算压到 4~6s，或者给已知死掉
的上游走缓存而不是每次重探。都是参数与策略选择，不是结构缺陷，留给下一步。