千万级 Web scraping 任务开跑前：代理流量、并发与容量怎么估算？

你准备跑 1000 万条网页采集任务，供应商通常会接着问：需要多少流量、多少并发、多少带宽，要在多长时间内完成？

这时只回答“1000 万请求”还不够。因为 1000 万可能是业务任务，也可能是页面执行次数；页面失败后会重试，浏览器还会加载额外资源。最终需要购买多少容量，取决于任务被放大了多少次，以及每次执行实际消耗多少流量。

假设小批量测试得到以下数据：每条任务平均执行 1.18 次，每次消耗约 180 KB，平均占用槽位 1.6 秒，需要在 24 小时内完成。代入计算后，大约需要 137 次执行/秒、383 个执行槽位、2124 GB 基础流量和 344 Mbps 峰值带宽。

下面就用这组数据算一遍。你只需要把示例数字替换成自己的项目数据。本文数字只用于演示，正式采购应使用小批量日志、供应商账单和峰值压测结果替换。

一、1000 万任务最终要买多少容量

这组任务会产生 1180 万次执行尝试。若代理按 GB 计费，基础用量约为 2124 GB；再预留 10% 的用量余量，询价时可以先按约 2336 GB 沟通。若方案按带宽提供容量，则应重点确认约 344 Mbps 的峰值带宽能否稳定支撑，同时检查 383 个执行槽位对应的机器、浏览器和下游处理能力。

如果购买的是网页抓取 API，不能把 1180 万次外部执行直接当成计费调用数。还要确认成功、失败、超时、附加渲染和供应商内部重试分别怎样计费，再按合同口径换算。

所以，容量规划其实分成两类问题：一类是整个项目会消耗多少流量或调用量，另一类是高峰时系统能否同时接住足够多的任务。前者决定总预算，后者决定能不能按时完成。

二、你只需要准备这 8 个输入

这 8 个数字最好来自一批有代表性的真实任务。测试样本要覆盖主要地区、常见页面和重型页面，避免只用最快、最轻的页面外推整个项目。

这里要分清四层口径：业务任务、执行尝试、浏览器内部 HTTP 资源请求和供应商计费单位。本文计算的是页面或接口的“执行尝试”，所以用“次执行/秒”表示速度，而不是直接写成 HTTP RPS。最终数据是否合格，可以沿用代理请求与有效数据的分层验收方法。

三、跟着公式算一遍

第 1 步：任务经过重试后会执行多少次

这意味着，1000 万条待交付任务在当前成功率和重试策略下，实际要运行 1180 万次。

第 2 步：平均每秒要启动多少次执行

这意味着，调度器平均每秒至少要启动约 137 次执行，才能在 24 小时内完成任务。

第 3 步：高峰时要接住多快的任务流

这意味着，调度器、执行器和代理链路要在高峰时接住约 191 次执行/秒，而不是只按全天平均值配置。

峰值系数应从真实时间序列中取得。定时任务同时启动、失败任务集中回流，都会把短时到达率推高。Grafana k6 的固定到达率执行器说明也体现了同一关系：给定到达率下，单次迭代越慢，需要的执行资源越多。

第 4 步：要准备多少执行槽位

这意味着，峰值阶段约有 306 个执行同时在途；加入 25% 容量余量后，需要准备 383 个可用槽位。

平均在途时间用于估算稳定状态下的槽位，P95 和 P99 则用来观察慢任务是否长时间占位。真正压测时，两组数据都要看。

第 5 步：流量和带宽分别是多少

这意味着，按 GB 计费时可以先按约 2336 GB 询价；按带宽提供容量时，则要验证约 344 Mbps 的峰值是否能稳定跑住。

峰值时段的任务结构若与日常差不多，可以直接用峰值系数放大平均带宽。若峰值时集中运行重型页面，则应重新测量这一时段的平均字节数。

四、哪些变化最影响预算

把一个变量改掉，结果会怎样变化？下面保留其余条件不动，用三种常见情形看预算最容易被哪里推高。

* 为了单独观察页面体积，表中暂时保持平均在途时间为 1.6 秒。真实页面变重后通常也会加载更久，此时应把新的在途时间代回槽位公式。

把 24 小时压到 12 小时：总流量几乎不变，但执行速率、槽位和峰值带宽约翻倍。更紧的交付时间，主要抬高瞬时容量。

把 180 KB 增加到 1.8 MB：总流量和带宽约扩大 10 倍。页面体积是按 GB 方案里最直接的预算放大器。

把尝试倍率从 1.18 提高到 1.50：执行次数、流量、槽位和带宽会一起上涨。减少无效重试，往往比单纯压低流量单价更有效。

五、拿着哪些数据去询价

三种计费方式，参数不能混用

如果团队已有采集器，只缺多地区住宅出口，可以拿“约 2336 GB 计划流量、目标地区、运行周期和峰值执行速率”去核对动态住宅代理。若任务长期持续运行、用量很高，则应同时比较按带宽计费的住宅代理方案，重点验证峰值字节速率和持续时间。

如果准备把浏览器渲染和页面解析交给外部服务，就要用供应商口径重新换算计费调用数。IPWeb 的网页抓取 API页面说明其按成功完成的 API 请求计费，正式询价时还应确认超时、失败和附加渲染的处理方式。

团队若尚未决定哪些环节自管，可以先看自建代理池、住宅代理与网页抓取 API 的选型边界；容量已经算清后，再用住宅 IP 购买指南核对套餐条件。

发给供应商的一页数据

1. 业务任务总量，以及各类任务占比；
2. 必须完成的时间窗口；
3. 实测执行尝试总数和尝试倍率；
4. 供应商口径下的平均计费字节；
5. 平均、P95 和 P99 在途时间；
6. 平均与峰值执行到达速率；
7. 计划执行槽位；
8. 目标地区、域名组及各组任务量；
9. 希望比较的计费方式：GB、带宽或 API 调用；
10. 总用量余量、峰值容量余量和超额处理方式。

真正开跑前再看这六项

最后别忘了看系统最窄的一环

把浏览器槽位、代理带宽、API 配额、目标端允许速率和入库能力都换算成“最终完成任务数/秒”，其中最小的那个才是整条链路的真实上限：

若队列已经积压，还要确认它能否在截止时间前排空：

分母小于或等于零时，队列不会自行排空。AWS 的基于 SQS 积压的扩缩容说明也把积压、允许延迟和平均处理时间结合起来判断，而不是只看队列条数。

把这 8 个输入换成自己的实测数据，再跑一次峰值验证，你就会得到一组能用于排期和询价的参数，而不是一个脱离业务条件的“千万级标准套餐”。采集任务仍应面向合法、授权或公开数据，并遵守目标站点条款、适用法律和合理访问速率。