代理并发、QPS 与响应时间
并发不是每秒请求数。先测量一次请求从发出到收到完整响应的端到端耗时，再结合在途请求上限、目标站点频率和任务处理开销估算吞吐量。
先区分并发、QPS 与响应时间
用在途请求和延迟估算吞吐
在请求持续供应、连接稳定且没有额外限速的稳态窗口内，可以使用 Little 定律对应的近似关系做容量起点。响应时间必须换算为秒。
完成 QPS ≈ 平均在途请求数 ÷ 平均端到端响应时间（秒）
这是容量估算，不是承诺值。目标站点限速、重试、队列空闲、响应体大小、解析和存储都会让实际吞吐更低。
当 p95 持续上升、429 增多或有效数据率下降时，继续增加并发通常只会放大排队与重试。应先定位目标限速、连接复用、响应体大小和解析瓶颈。
一个浏览器页面不是一个代理请求
Requests、Axios 等 HTTP 客户端通常由代码显式决定每一次请求；浏览器则会根据页面自动并行加载资源。一个页面可能同时消耗 10-20 个并发线程，也可能更多。
页面导航本身的 HTML 请求，之后还会触发解析与子资源发现。
JavaScript、CSS、图片、字体和媒体文件可能同时发起多个连接。
XHR、Fetch、GraphQL、埋点与长轮询会在页面加载后继续占用连接。
记录能解释容量的指标
request_started_at请求或导航开始时间duration_ms收到完整响应或页面达到完成条件的耗时status_code区分代理认证、目标拒绝、限速与服务端错误bytes_received评估流量套餐与大对象下载成本retry_count观察重试是否掩盖目标站点或网络问题target_host按目标域名独立计算QPS与错误率session_id需要粘性路由时定位同一SESSION的行为valid_record_count用有效数据而不是HTTP成功数衡量吞吐用小步阶梯找到稳定并发
- 1从低并发建立基线
先确认代理出口、目标响应和解析结果正确，记录平均值与p95。
- 2每轮只提高一个变量
逐步增加worker或单域名并发，不同时改变重试、超时与请求间隔。
- 3观察有效吞吐是否继续增长
若QPS不再增长但延迟、429或重试率上升，应回退到上一档。
- 4预留生产余量
不要长期运行在瞬时极限，给目标抖动、代理切换和任务峰值留下空间。
容量模型与代理产品要匹配
常见问题
50 并发是否一定能达到 50 QPS？
不一定。稳态近似关系是吞吐量约等于并发数除以平均端到端响应时间。若平均响应时间为 2 秒，50 个持续饱和的在途请求理论上约为 25 QPS；限速、重试、解析和任务队列会继续降低实际值。 查看重试与退避策略
浏览器打开一个页面为什么会占用多个并发线程？
浏览器除主文档外还会并行请求 JavaScript、CSS、图片、字体和接口。一个页面可能同时产生 10-20 条代理请求，实际数量取决于页面资源、缓存、资源拦截和浏览器连接调度。 查看 Selenium 完整案例
并发线程套餐是否等于目标站点允许的并发？
不是。套餐并发是代理侧可同时承载的在途请求上限，目标站点仍可能有更低的频率限制。应按目标域名单独设置并发、QPS和退避策略。