如何测量 QPS
查询可以是数据库查询、API 调用、搜索请求或 HTTP 请求。比较 QPS 数据前，应先确认统计的是收到的请求、成功完成的请求，还是产生任何结果的请求。
用查询总数除以测量时长（秒），即可算出平均 QPS。如果某个 API 在 10 秒内完成 600 个请求，平均吞吐量就是 60 QPS。平均值可能掩盖短时峰值，所以监控通常会同时报告平均值，以及按 1 秒窗口测得的峰值。
QPS 高并不代表性能一定好。失败的请求也会推高该数值，而响应缓慢仍会影响用户体验。
QPS 与并发和延迟的区别
QPS 衡量速率。并发统计正在处理的请求数量，延迟衡量每个请求需要多长时间。
| 指标 | 衡量内容 | 示例 |
|---|---|---|
| QPS | 每秒请求数 | 每秒 20 个请求 |
| 并发 | 正在处理的请求数 | 10 个未完成的请求 |
| 延迟 | 每个请求的耗时 | 500 毫秒 |
负载稳定时，平均并发约等于 QPS 乘以平均响应时间。QPS 为 20、延迟为 0.5 秒时，预计约有 10 个请求正在处理。该估算要求平均值稳定，且测量区间边界一致。出现短时突发流量时，瞬时 QPS 和并发可能并不一致。
QPS 对代理的重要性
使用代理时，可以测量客户端与代理之间的 QPS，也可以测量代理与目标之间的 QPS。重试和代理错误可能导致两者的数据不同。一个网页也可能触发多个 HTML、脚本和图片请求，因此每秒页面数并不等于 QPS。
网站、API、CDN 和防火墙通常会按 IP 地址、账号或 API 密钥限速。使用更多代理 IP 发送请求会改变流量来源，但并不代表可以超出网站规定的限制。流量过大时，可能会收到 429 Too Many Requests 响应。
如何控制 QPS
- 查看公开的限制。 遵守 API 文档、robots.txt 和网站条款。
- 限制总速率。 对所有工作进程和代理统一限速，而不是只分别限制每个代理。
- 限制并发。 使用队列，避免响应变慢时出现数量失控的未完成请求。
- 处理 429 响应。 如果响应中包含
Retry-After，应按其要求等待，并在重试前使用指数退避。 - 测量有效吞吐量。 在跟踪延迟和错误率的同时，记录成功请求的 QPS。
常见问题
多高的 QPS 才算好？
这取决于具体系统及其公开限制。合理的 QPS 应当可以持续维持，在满足工作负载需求的同时，不会增加延迟或错误。
QPS 和每秒请求数相同吗？
通常相同。“QPS”常用于数据库、搜索系统和 API，“每秒请求数”则常用于网络流量。无论使用哪个名称，都应确认该指标具体统计什么。
使用更多代理会提高 QPS 吗？
不会自动提高。更多代理可以把请求分散到不同 IP 地址，但客户端、代理网关和目标服务仍有容量与限速限制。