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 待修)

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% 成功率——明显压不满。
低速恢复锁死: 恢复条件要求 10 分钟短窗 successS≥0.995,低速涓流(~1% captcha 占比)下永远达不到;实际恢复全靠 captcha==0 清洁段触发 clean-fast。05:00–06:10 在 24–42/min 滞留 70 分钟,11:35–12:14 滞留 39 分钟。
累计盲: 控制器只看窗口不看全天累计。23时 94.90% 把累计从 98.19% 压到 98.06%,控制器没有任何累计感知的削波/放行;反过来,结尾累计已锁定 >98% 时,00:43 仍因 4 个 captcha(0.96%)从 73.3 切到 51.3,未能利用富余度。深切能保护累计是"暴露量最小化"的副产品,不是设计使然。

7. v5 优化方向(待下一个真实 24h 验证,本报告不做任何数字预测)

恢复条件按量归一: 低速时用绝对失败数而非占比判恢复(如短窗 captcha≤1 且 sent≥N,或改用指数衰减基线),消除 05时/11时式滞留。
ongoing 切加量下限: 窗口 sent 不足阈值时只记信号不切速,避免小分母瀑布。
累计感知: 把全天累计成功率与 98% 线的余量引入削波深度(余量大→浅切)与恢复速度(余量大→快爬)。
扩 workers: 实测饱和 ≈96–135/min 由 workers=12 × 延迟决定;提高 worker 数是把 100–400 段天花板变为真实吞吐的最短路径,同时配合 fetch 桶扩容评估。
池空 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 系列文件自身口径。

9.5 KiB Raw Blame History Unescape Escape