2025 年 11 月，我给 Lianjia-crawler 增加了线程池、全局与区域限速器、独立写入线程和请求指标记录。为了判断并行版本是否真的更快，我又做了三轮串行与并行对比。
原报告最后给出了“p < 0.01”“高可信度”和“稳定提升 3～4 倍”的结论。重新检查实验设计后，我认为这些表述不能成立。
三轮测试实际观察到了什么
每轮测试约包含 10 个请求，记录如下：
| 测试 | 串行耗时 | 并行耗时 | 观测加速比 |
|---|---|---|---|
| 基线配置 | 83.95 秒 | 21.82 秒 | 3.85x |
| 移除延迟保护 | 102.36 秒 | 23.46 秒 | 4.36x |
| 调整延迟配置 | 89.37 秒 | 29.78 秒 | 3.00x |
直接对三组比值做描述性汇总，可以得到：
- 平均加速比约
3.74x； - 中位数约
3.85x； - 观测范围为
3.00x～4.36x。
这些数据足以说明：在当时的三轮运行里，并行版本都比对应的串行版本更快。但它们还不足以推断稳定的总体性能收益。
为什么不能发布 p 值
三轮测试并不是同一条件下的三次重复实验。串行端先后使用了 PAGE_DELAY、完全取消延迟、保留 REQUEST_DELAY 三种配置；请求顺序和时间也没有随机化。目标服务的负载、网络状态和 IP 累积请求都会继续影响响应时间。
因此，把三组耗时直接放进 t 检验，相当于假设它们来自同一分布下的独立重复样本。这个假设与实验过程不符。即使计算程序能输出一个很小的数字，它回答的也是一个并不存在的实验问题。
样本量也只有 3 组。此时均值、标准差和置信区间都会非常不稳定，更不应该据此给实验打出“8.5/10”或“High Confidence”。
可以保留的结论
更准确的说法是：
在三组小规模观测中，并行版本耗时均低于对应串行版本，观测加速比为 3.00x～4.36x。由于每轮配置不同且没有足够重复次数，这只能作为后续实验的先验线索，不能作为显著性或稳定收益的证明。
工程机制本身仍然合理。网络等待可以被其他 worker 覆盖，令牌桶可以限制请求突发，写入线程可以减少磁盘操作对抓取调度的干扰。但“机制合理”和“收益已经被严格验证”是两件事。
下一次实验应该怎么做
如果重新验证，我会把实验改成下面这样：
- 固定串行与并行版本的请求延迟、页面范围、区域和解析逻辑；
- 把一次串行和一次并行组成配对，随机或交替执行顺序；
- 先预热，再至少记录 20 组配对运行；
- 保存每个请求的开始时间、响应耗时、状态码与重试次数；
- 同时报告中位数、P95、成功率和配对差值区间；
- 在站点允许范围内保持低 QPS，避免为了跑分改变目标服务状态。
这次复盘最有价值的部分，不是把旧结论换成另一个更漂亮的数字，而是承认证据边界。性能优化可以从一次小实验开始，但对外发布的确定程度必须与实验质量匹配。