接口性能概述
先问个问题：你调完一个接口，看它返回了正确数据，就觉得它“性能好”吗？
我之前也是这样想的。直到有一次线上报警，请求量一大，系统直接瘫了。数据全对，可就是慢，慢到用户直接关掉网页。那一刻我才明白——接口性能不是“能用”，而是“在预期时间内、在预期负载下、稳定地能用”。
什么是接口性能？
接口性能可以理解成系统的“承重能力”和“响应速度”的综合表现。就像一个人，光跑得快不行，还得能扛着东西跑。接口也一样：既要返回快，又要在多人同时调用时不掉链子。
我记得在某个金融项目里，交易接口的吞吐量设计目标只有 500 TPS。结果上线前压测发现，并发一上 200 就开始丢数据。说白了，就是“承重能力”没到位。所以我说，接口性能就是衡量系统在多快、多稳、多准三个维度上的表现。
核心性能指标
日常工作中，我愿意用四个指标来给接口“体检”。下面这张表我每次培训都会拿出来讲，你最好也记一下。
| 指标 | 定义 | 典型衡量方式 | 常见问题 |
|---|---|---|---|
| 响应时间 | 从发送请求到收到完整响应的时间 | P50、P95、P99 百分位 | 只看平均值，忽略尾部延迟 |
| 吞吐量 | 单位时间内处理的请求数 | TPS（每秒事务数）、QPS（每秒查询数） | 只追求高 TPS，不关心响应时间是否恶化 |
| 并发数 | 同一时刻系统正在处理的请求数 | 活跃连接数、线程数 | 盲目提升并发配置，导致资源争抢 |
| 错误率 | 失败请求占总请求的比例 | 5xx 率、超时率、业务错误码率 | 忽略缓慢导致业务超时（不算 5xx 但实际失败） |
指标之间的“博弈”
这四兄弟不是孤立存在的。你提高并发数，响应时间往往跟着涨；你想压高吞吐量，错误率也可能抬头。举个我踩过的坑：某下单接口，平时响应时间 50ms，我拼命调连接池把并发数拉到 1000，结果响应时间飙到 2 秒，错误率从 0.1% 跳到 8%。说白了，这几个指标是个跷跷板。
下面这张图很直观地展示了它们的关系。建议你把它存在脑子里。
我个人的分析习惯
每次拿到一个新接口，我不会直接上压测。我的步骤很固定：
- 先定目标：跟产品要一个“可接受的响应时间”和“峰值并发数”。没有目标，后面都是瞎忙。
- 单线程摸底：发一次请求，看响应时间、返回大小、是否有缓存错过。我记得以前有个同事一来就开 500 线程压，结果发现接口里有个死循环。浪费了一下午。
- 阶梯加压：从 10 个并发开始，每 10 秒加 20 个，同时记录 TPS 和错误率。直到拐点出现——就是吞吐量不涨、错误率开始飙升的那个点。
- 找到瓶颈资源：看是 CPU 满了？数据库连接池用完了？还是网络带宽打满了？这个我在后面章节会细讲。
- 记录基线：把压测结果固化，方便回归对比。我曾经因为没记录，优化后反而更烂了，差点背锅。
常见误区与避坑
误区一：只盯响应时间，不看并发
我曾经优化一个列表接口，单请求从 200ms 降到了 30ms，开心极了。结果压测一上来，吞吐量反而没涨。为什么？因为数据库连接数不够，虽然每个请求快了，但排队时间反而变长了。你看，只看一个指标会误导自己。
误区二：错误率只看 HTTP 5xx
我见过一个系统，返回 200 但里面带了业务错误码，比如“库存不足”。这种不算 5xx，但用户操作失败了。所以我的习惯是把业务错误码也纳入错误率统计，统一算作“失败”。
误区三：压测时用本地环境或测试数据
很多团队刚上来用少量、完全随机的数据模拟，结果线上真实数据分布完全不一样——有些大字段、热键、慢查询根本没暴露。我建议压测数据量至少是线上数据的 70%，并且要包含冷热数据分布。
这四个指标我们今天就聊到这儿。说的白一点，理解它们之间的“博弈”，才是性能优化的第一步。后面我会带你一步步深入到各个场景里，看看具体怎么定位和解决。