比较同一使用路径
采用十进制千字节的虚构示例：原方案调用 100 次，每次响应 100 kB；候选方案调用 20 次，每次 50 kB。总量从 10000 降至 1000 kB，减少 90 %，但不能据此认定延迟同比下降。只统计响应正文，不含请求及头部。
| 虚构指标 | 原方案 | 候选方案 |
|---|---|---|
| 调用次数 | 100 | 20 |
| 每次响应大小 | 100 kB | 50 kB |
| 总传输量 | 10000 kB | 1000 kB |
| 全程耗时 | 需要测量 | 需要测量 |
先减少工作，再增加并发
- 只请求需要的字段，遵守分页约定。批处理须定义上限和部分成功的处理；页面越大并不总是越快。
- 在上下文和新鲜度允许时复用连接及响应。限制并发，同时测量服务端工作量与排队。
- 设定总期限和尝试次数上限。对暂时故障的重试加入随机等待，并检查各层是否已在重试。
避免重复执行已完成的操作
客户端超时不能证明服务端已取消。再次创建或付款前，应核对状态以及供应方的幂等机制。用有代表性的负载比较全程耗时、错误和数据正确性。
一手资料
- IETF RFC 9110 — HTTP Semantics [EN]
- AWS Builders’ Library — Timeouts, retries and backoff with jitter [EN]
检查单个 API 响应背后的工作
单个 GraphQL 查询可以触发多个下游调用。客户端可见的延迟可能掩盖解析器、列表和遍历关系的成本。
- 跟踪从客户端到下游服务的操作。
- 比较字段成本和实际有效量。
- 缓存前绑定列表和重复查询。
一手资料：OWASP — GraphQL Cheat Sheet. 相关方法：阅读实用指南.
Retry-After：等待、预算与重试决策
此语言版本的详细参考说明以英语提供。
Reducing API calls includes controlling repetition
An API optimisation should count attempts reaching the dependency rather than only requests initiated by the screen.
- Trace SDK and proxy retries under one logical identifier.
- Avoid shortening server instructions merely to fit a budget.
- Verify an uncertain write’s state before creating a new intention.
Explore Retry-After and the retry model →
References reviewed · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS