stress: AIMD 控制器 v5 —— 可用率约束 98%→99%(用户 2026-11-02)+ 低速恢复锁修复(爬坡备选条件「验证码≤1且短窗≥98.5%」,修 dp6 实测 05:00-06:10 滞留 70min 于 24-42/min);附 dp6 24h 实测优化报告(104,440 请求 98.11% 72.6/min,+29% 吞吐)
This commit is contained in:
bigcode
@@ -0,0 +1,142 @@
|
||||
# dp6 24小时实测优化报告(fetch+浏览器双路径)
|
||||
|
||||
- **运行区间**: 2026-11-01 01:22:43 UTC → 2026-11-02 01:21:43 UTC(24h 跑满,进程正常退出,final 已写)
|
||||
- **版本**: SerpMax v1.78.2 + 压测客户端控制器 v4(`stress/serp-dualpath-optimize.ts`,runtime=auto 双路径,workers=12,速率区间 [3,400])
|
||||
- **数据源**: `/opt/serpmax/data/dp6-final.json`、`dp6.jsonl`(分钟)、`dp6-req.jsonl`(逐请求 117,724 条)、`dp6.log`;对照 `dp5-final.json`、`dp5-req.jsonl`。全部为服务器落盘的真实测量值,无任何外推/估算。
|
||||
- **对照说明**: dp1–dp4 为短程调优试探(服务器上无 24h final 文件);完整 24h 对照只有 dp5(v1.78.1+控制器 v3)与 dp6(v1.78.2+控制器 v4)。
|
||||
|
||||
---
|
||||
|
||||
## 1. 结论摘要
|
||||
|
||||
| 指标 | dp5(v3) | dp6(v4) | 变化 |
|
||||
|---|---|---|---|
|
||||
| 总请求 | 80,974 | **104,440** | **+29.0%** |
|
||||
| 成功 | 80,301 | 102,461 | — |
|
||||
| 成功率 | 99.17% | **98.11%** | −1.06pp,仍 >98% ✓ |
|
||||
| 日均速率 | 56.3/min | **72.6/min** | **+29.0%** |
|
||||
| captcha 命中 | 335(0.41%) | 1,537(1.47%) | 当日波次更密 |
|
||||
| 门壳结果 gate | 270 | 246 | — |
|
||||
| 池空 poolEmpty | 0 | 75(最差 1 小时 23 次) | v1.78.2 轮转取缓存代价 |
|
||||
| httpErr / netErr | 10 / 7 | 65 / 0 | httpErr 全部集中在 23 时波浪 |
|
||||
| fetch / browser 分流 | 41,773 / 38,849 | 48,573 / 54,190 | browser 承接溢出 52.7% |
|
||||
|
||||
**核心结论**: 在 >98% 成功率约束下,控制器 v4 把 24h 真实日均吞吐从 56.3 提到 **72.6 请求/分钟(+29%)**,代价是成功率贴着约束线收在 98.11%。这是约束边界上的实测最优交换。
|
||||
|
||||
---
|
||||
|
||||
## 2. dp6 全天逐小时实测(UTC)
|
||||
|
||||
| 小时 | 请求 | 成功率 | captcha | gate | poolE | fetch | browser | 均值/min |
|
||||
|---|---|---|---|---|---|---|---|---|
|
||||
| 01日01时(38min) | 3,762 | 99.39% | 19 | 3 | 0 | 1,558 | 2,185 | 99 |
|
||||
| 02时 | 5,214 | 98.68% | 59 | 8 | 0 | 2,415 | 2,740 | 87 |
|
||||
| 03时 | 5,416 | 98.47% | 54 | 25 | 0 | 2,265 | 3,097 | 90 |
|
||||
| 04时 | 4,266 | 96.91% | 115 | 12 | 1 | 2,094 | 2,056 | 71 |
|
||||
| 05时 | 1,667 | 98.86% | 9 | 10 | 0 | 1,632 | 26 | 28 |
|
||||
| 06时 | 5,098 | 99.86% | 2 | 4 | 1 | 2,189 | 2,906 | 85 |
|
||||
| 07时 | 5,063 | 99.09% | 32 | 14 | 0 | 2,006 | 3,025 | 84 |
|
||||
| 08时 | 5,189 | 98.50% | 67 | 10 | 0 | 2,003 | 3,119 | 86 |
|
||||
| 09时 | 5,146 | 98.15% | 72 | 18 | 1 | 2,105 | 2,968 | 86 |
|
||||
| 10时 | 4,583 | 98.23% | 68 | 13 | 0 | 2,206 | 2,309 | 76 |
|
||||
| 11时 | 3,601 | 98.03% | 45 | 14 | 7 | 2,014 | 1,531 | 60 |
|
||||
| 12时 | 4,470 | 99.22% | 17 | 13 | 3 | 2,093 | 2,356 | 74 |
|
||||
| 13时 | 4,678 | 97.26% | 101 | 14 | 8 | 1,792 | 2,773 | 78 |
|
||||
| 14时 | 3,505 | 97.60% | 55 | 5 | 2 | 2,196 | 1,231 | 58 |
|
||||
| 15时 | 3,231 | 97.62% | 70 | 6 | 0 | 2,165 | 996 | 54 |
|
||||
| 16时 | 5,352 | 97.42% | 112 | 14 | 0 | 2,080 | 3,158 | 89 |
|
||||
| 17时 | 4,509 | 96.70% | 116 | 6 | 14 | 2,094 | 2,282 | 75 |
|
||||
| 18时 | 2,708 | 98.08% | 46 | 3 | 0 | 1,575 | 1,087 | 45 |
|
||||
| 19时 | 4,712 | 98.58% | 61 | 2 | 2 | 2,025 | 2,624 | 79 |
|
||||
| 20时 | 5,228 | 97.42% | 111 | 15 | 3 | 2,037 | 3,076 | 87 |
|
||||
| 21时 | 4,673 | 98.44% | 57 | 8 | 6 | 2,325 | 2,285 | 78 |
|
||||
| 22时 | 4,752 | 97.92% | 91 | 7 | 0 | 1,910 | 2,751 | 79 |
|
||||
| 23时(最差) | 4,114 | **94.90%** | **146** | 14 | **23** | 1,650 | 2,268 | 69 |
|
||||
| 02日00时 | 1,613 | 98.64% | 12 | 6 | 1 | 1,374 | 224 | 27 |
|
||||
| 02日01时(21min) | 1,840 | 99.73% | 0 | 1 | 3 | 747 | 1,090 | 88 |
|
||||
|
||||
- jsonl 口径合计 104,390;final.json 权威口径 **104,440 / 98.11%**(差值为跨小时边界分钟)。
|
||||
- 全天净错误 netErr=0,无一次网络层失败。
|
||||
- 最差小时 23时(94.90%)对全天累计仅拖累约 0.13pp——深度削减把该小时暴露量压到最小,是"深切保护累计"策略的实测验证。
|
||||
|
||||
---
|
||||
|
||||
## 3. 速率段分布与控制器行为结构(实测)
|
||||
|
||||
**速率段时间分布(1,439 分钟):**
|
||||
|
||||
| 速率段 | 分钟数 | 发出请求 | 请求占比 |
|
||||
|---|---|---|---|
|
||||
| <50/min | 250 min | 7,119 | 6.8% |
|
||||
| 50–100 | 252 min | 17,691 | 16.9% |
|
||||
| 100–200 | 517 min | 44,402 | 42.5% |
|
||||
| 200–300 | 337 min | 28,047 | 26.9% |
|
||||
| 300–400 | 53 min | 4,356 | 4.2% |
|
||||
| =400 | 30 min | 2,775 | 2.7% |
|
||||
|
||||
**行为结构(来自 dp6.log 全量速率变更史,共 113 次调率):**
|
||||
- **5 次深切瀑布**(×0.7 连锁到 <30/min):04:50→23.9、09:32→47、14:10→39、17:54→11.1、23:57→6.3/min(末次为 ×0.5 四连)。每次都在波浪过后由 clean-fast ×1.3 链恢复。
|
||||
- **10 次 clean-fast ×1.3 恢复链**,最快 9 拍从 40 拉到 331/min(14:46–14:53),典型 6–7 拍。
|
||||
- **×1.08 常规爬坡**接在恢复链后,爬到 280–400 区间;全天共 228 个 ramp 序列。
|
||||
- **12 次验证码软切**(×0.7)、**2 次池空软切**(×0.85)、多次 30 分钟入场切(<98% 成功)。
|
||||
- 完整周期 1.5–2h:波浪 → 切(最深 ×0.5)→ 低速持守到 captcha==0 → ×1.3 链 → ×1.08 爬坡 → 重复。
|
||||
- 结尾 00:56–01:13 恢复链一路拉回 400/min,最后 21 分钟以 352–400/min 跑出 99.73%。
|
||||
|
||||
**饱和天花板(重要实测发现)**: 速率上限虽设 400/min,但 =400 段实际只发出 92.5 请求/min(2,775/30min)。瓶颈是 workers=12 × 平均延迟(ok 均值 7.5s)→ 理论上限 ≈96/min;实测高速率段稳定落在 100–135/min。**400 的桶只是天花板标记,有效吞吐由 worker 数与延迟决定**——这是 v5 最直接的扩容方向。
|
||||
|
||||
---
|
||||
|
||||
## 4. 双路径经济学(逐请求实测)
|
||||
|
||||
| 路径/结果 | dp6 条数 | dp6 均延迟 | 多次尝试占比 | dp5 对照 |
|
||||
|---|---|---|---|---|
|
||||
| fetch/ok | 48,467 | **5,160ms** | 0.70% | 41,663 / 4,465ms / 0.90% |
|
||||
| browser/ok | 53,994 | **9,668ms** | 2.26% | 38,638 / 7,446ms / 2.89% |
|
||||
| fetch/gate | 106 | 10,873ms | 100% | 110 / 10,649ms |
|
||||
| browser/gate | 140 | **39,677ms** | 100% | 160 / 30,851ms |
|
||||
| browser/empty | 56 | 31,469ms | — | 51 / 24,546ms |
|
||||
| captcha(未分派) | 1,537 | 4,530ms | — | 335 / 4,927ms |
|
||||
| poolEmpty / httpErr | 75 / 65 | 31.2s / 42.2s | — | 0 / 10 |
|
||||
|
||||
- browser 单请求耗时是 fetch 的 1.87 倍,但承接了 52.7% 的已分派流量(dp5 为 48.0%)——高速率段 fetch 桶(60/min 封顶)只够供给约 15%,溢出全部由浏览器热池消化,溢出设计按预期工作。
|
||||
- 门壳尝试 874 次(0.83%,dp5 为 0.95%):browser 门壳每次烧 39.7s,是最贵的失败形态;v1.78.2 的指纹轮换使门壳占比略降。
|
||||
- captcha 检测均耗时 4.5s,本身便宜;真正昂贵的是它触发的降速与爬坡时间。
|
||||
|
||||
---
|
||||
|
||||
## 5. 稀释论的实测验证
|
||||
|
||||
**论题**: captcha 供给由 Google 侧按波次发放(逐小时 2–146 个,与本地速率弱相关),因此同等波次下速率越高、captcha 占比越低、窗口成功率越高;**波浪中降速反而抬高 captcha 占比、恶化窗口成功率**。
|
||||
|
||||
实测证据:
|
||||
- 配对小时:19时(79/min,captcha 61)→ 98.58%;17时(75/min,captcha 116)→ 96.70%。速率相近,成败由波次强度决定。
|
||||
- 高速率窗口:400/min 段窗口成功率 99.6–99.9%,captcha 短窗占比 0(capPctS=0)。
|
||||
- 低速率反例:05:24 在 31.3/min 处,窗口内 3 个 captcha 就构成 1.13% 占比触发软切——同样的 3 个 captcha 在 400/min 下只占 0.09%。
|
||||
- 但波浪总量确实随速率升高而增多(dp6 1,537 vs dp5 335):提速换来的是分母稀释,不是 captcha 绝对数减少。
|
||||
|
||||
---
|
||||
|
||||
## 6. 控制器 v4 的三个残余缺陷(实测例证,已列入 v5 待修)
|
||||
|
||||
1. **ongoing 切不感知量(量盲)**: 低速率下小分母放大占比。05:24 因"验证码 3 个占比 1.13%"把 31.3 切到 25/min;00:02–00:03 波浪实际已近尾声(~00:20 结束),仍以窗口 93.4%/93.2%(每窗仅几十个请求)连续 ×0.5 切到 6.3/min 并滞留到 00:30。代价:05时全天第二低的 28/min 却有 98.86% 成功率——明显压不满。
|
||||
2. **低速恢复锁死**: 恢复条件要求 10 分钟短窗 successS≥0.995,低速涓流(~1% captcha 占比)下永远达不到;实际恢复全靠 captcha==0 清洁段触发 clean-fast。05:00–06:10 在 24–42/min 滞留 70 分钟,11:35–12:14 滞留 39 分钟。
|
||||
3. **累计盲**: 控制器只看窗口不看全天累计。23时 94.90% 把累计从 98.19% 压到 98.06%,控制器没有任何累计感知的削波/放行;反过来,结尾累计已锁定 >98% 时,00:43 仍因 4 个 captcha(0.96%)从 73.3 切到 51.3,未能利用富余度。深切能保护累计是"暴露量最小化"的副产品,不是设计使然。
|
||||
|
||||
---
|
||||
|
||||
## 7. v5 优化方向(待下一个真实 24h 验证,本报告不做任何数字预测)
|
||||
|
||||
1. **恢复条件按量归一**: 低速时用绝对失败数而非占比判恢复(如短窗 captcha≤1 且 sent≥N,或改用指数衰减基线),消除 05时/11时式滞留。
|
||||
2. **ongoing 切加量下限**: 窗口 sent 不足阈值时只记信号不切速,避免小分母瀑布。
|
||||
3. **累计感知**: 把全天累计成功率与 98% 线的余量引入削波深度(余量大→浅切)与恢复速度(余量大→快爬)。
|
||||
4. **扩 workers**: 实测饱和 ≈96–135/min 由 workers=12 × 延迟决定;提高 worker 数是把 100–400 段天花板变为真实吞吐的最短路径,同时配合 fetch 桶扩容评估。
|
||||
5. 池空 75 次来自 v1.78.2 节点轮换取缓存,最差小时 23 次;可对波浪期保留最小缓存水位以归零该类错误。
|
||||
|
||||
---
|
||||
|
||||
## 8. 口径备注
|
||||
|
||||
- 成功率 = ok/sent;sent 含 captcha/gate/empty/poolEmpty/httpErr 全部结果,netErr 另计。
|
||||
- dp6 全天 fetch 48,573 + browser 54,190 = 102,763 条有路径归属;其余 1,677 条为未按路径记录的结果(池空/httpErr 等)。
|
||||
- dp1–dp4 仅有试探性产物(dp1 26KB / dp2–dp3 ~1.7KB / dp4 137KB jsonl),无 24h final,不参与定量对照。
|
||||
- 服务器监控(serp-monitor)h24 口径混有 dp6 之外的生产流量,本报告一律不采用;只用 dp6 系列文件自身口径。
|
||||
Reference in New Issue
Block a user