代理容量并不等于供应商允许的最大并发数字。系统可能仍能建立连接，但延迟已经升高、重试快速增加、有效吞吐反而下降。容量规划要找出的是：在成功率、延迟、成本和合规要求内能够长期维持的最高可持续并发量。
先建立工作负载模型
测试前记录真实业务特征：
- 正常与高峰期每分钟请求数；
- 目标国家和目标类型；
- 常见及最大响应大小；
- 会话时长，以及是否要求连续性；
- 可接受的中位与第 95 百分位延迟；
- 超时与重试预算；
- “验证成功结果”的明确标准。
轻量 API、大页面和多步骤会话的资源消耗不同，不应共用一个并发上限。
分清四类上限
1. 客户端上限
应用可能先耗尽文件描述符、套接字、CPU、内存或事件循环容量。测试时必须记录客户端资源，避免把本地瓶颈误判成代理性能问题。
2. 代理线路上限
不同地区、网关池和会话模式的容量可能不同。每次测试都要标记网关、地区、会话策略和认证方式。
3. 目标站点上限
目标端可能有速率限制，并在请求压力升高时降低服务。应遵守公开限制、robots 指令、访问控制和使用条款。容量测试不代表可以绕过限制。
4. 业务质量上限
即使连接还能完成，只要验证成功率、延迟、数据时效或成本超出服务目标，就已经到达真正的容量上限。
使用阶梯式压力测试
从保守基线开始，以固定阶段增加并发，例如 5、10、20、40、80 个工作线程。每个阶段都要持续足够时间，使连接复用、IP 轮换、DNS 行为和正常响应波动充分出现。不要一开始就使用标称最大值。
每个阶段至少记录：
- 尝试请求与验证请求的每秒吞吐；
- 首次成功率和有限重试后的最终成功率；
- 中位、p95 与 p99 延迟；
- 超时、连接、认证及内容校验错误；
- 每条有效结果的字节数；
- 活跃会话、队列深度和重试量；
- 每次成功请求的代理、计算和人工成本。
当错误明显加速、延迟超标、队列持续增长或有效吞吐不再提升时，应停止增加压力。
找到饱和拐点
绘制并发量与有效吞吐、p95 延迟的关系。饱和拐点之后，增加工作线程只能带来很少的有效吞吐，却显著增加延迟、错误或成本。
例如，40 个线程可以在合格延迟内提供每秒 34 条有效结果；增加到 80 个线程后，吞吐只升至 37，但 p95 延迟翻倍、重试量变成三倍。后者数字更大，实际运营质量却更差。
建立安全运行区间
生产环境不应长期运行在测试边缘。要为目标站波动、地区故障和流量突增预留余量。可先把生产上限设为实测可持续上限的 60%–80%，再根据真实数据调整。
建议分别设置以下维度的上限：
- 国家或地区；
- 目标域名或端点组；
- 请求与响应大小；
- 静态、粘性或轮换会话；
- 正常与高峰时段。
控制重试与队列
重试会产生隐藏并发。100 个主请求若同时触发 30 次重试，真实压力就是 130。应设置较小的重试预算，使用带随机抖动的指数退避，并按错误类型决定是否重试。永久认证错误、无效请求和明确拒绝不应重试。
队列必须有上限。无限队列会把过载隐藏到请求已经失去业务价值时。队列等待时间超标后，应拒绝、延迟或减少新任务。
避免常见测试错误
- **只测一个容易的域名：**应使用真实目标组合。
- **只看 HTTP 状态：**还要验证内容与时效。
- **忽略预热：**区分连接建立与稳定运行阶段。
- **意外复用同一 IP：**确认会话行为符合设计。
- **同时修改多个变量：**把并发调整与超时、重试调整分开。
- **只跑短时突发：**还要测试持续压力和恢复过程。
- **保存敏感日志：**删除凭据和不必要的个人数据。
生产监控
并发量必须与验证吞吐、p95 延迟、重试率、队列等待时间和单位成功成本一起监控。不要只在完全失败时告警；队列持续上升而吞吐不变，就是早期饱和信号。
当目标组合、响应大小、地区分布、代理套餐、客户端运行环境或验证规则发生变化后，应重新测试。
容量规划清单
- 定义验证成功和延迟目标。
- 测试前拆分工作负载。
- 建立低压力基线。
- 分阶段增加并发。
- 每个阶段保持到稳定状态。
- 分开记录首次与重试后结果。
- 找出吞吐与延迟的饱和拐点。
- 为生产设置安全余量。
- 限制队列和重试预算。
- 跨地区、高峰时段重复测试。
常见问题
最大并发连接数就是容量吗？
不是。它通常只是技术允许值。可持续容量必须同时满足有效成功率、延迟和成本目标。
所有地区应该使用同一上限吗？
不应该。资源池、距离、目标和响应大小不同，重要地区应分别建立安全区间。
多久重新测试一次？
在工作负载或基础设施明显变化后重新测试；高流量线路还应定期复核，并在完整评估之间使用小规模金丝雀测试。
团队可以查看 98IP 住宅代理容量方案，并在扩大规模前应用这套受控测试方法。仅测试已授权目标，遵守目标规则，并尽量减少数据留存。
