apipost使用教程-如何进行接口性能测试

接口功能测通了，不代表上线扛得住。很多人打开 ApiPost 想做性能测试，却卡在不知道该压多少并发、该看哪几个指标、结果出来怎么判断好坏。这篇按“准备—施压—看数—排查”的顺序给你一套可执行的流程，也说明什么情况下压测结论不能直接当上线依据。

接口功能测通，只说明参数和逻辑没错，不代表上线扛得住。很多人打开 ApiPost 想顺手做性能测试，却卡在三个问题上：该压多少并发、该盯哪几个指标、跑出来的数是好是坏。这三个问题没有标准答案，但有固定的判断顺序。

下面按「准备—施压—看数—排查」走一遍，每一步都给可执行的动作和判断标准，最后说明什么情况下这次压测的结论不能当上线依据。整套流程用 ApiPost 的接口请求加上性能测试模块就能完成，不需要额外搭一套压测框架。

压测前先备好三样东西

压测跑之前先把三样东西备齐，否则跑出来的数字没法解释。第一样是可复用请求：在 ApiPost 里把目标接口调通，鉴权头、路径参数、请求体全部固定下来，性能测试直接复用这份请求定义，保证压的和线上跑的是同一份逻辑。

• 量单次延迟基线：手动发几次，记录响应时间的分布，不要只记一次；有 /tools/speed-test 这类工具的话顺手量一下网络侧延迟，后面才能分清是接口慢还是链路慢
• 准备独立测试环境和专用测试账号，写操作类接口要有数据回滚方案，拿线上库直接压是常见事故来源
• 把压测目标写下来：是验证某个并发下能不能稳定，还是找拐点，目标不同，梯度设法和看数重点都不一样

并发梯度怎么设，而不是一上来就拉满

并发数从小档往大档加，别第一步就拉到很高。先跑低档，看响应时间是否稳定、错误率是否为零，再逐级往上加。加的过程中盯住响应时间的斜率：缓慢线性增长属于正常，某一档之后突然跳升，这一档附近就是拐点，后面继续压意义不大，该回头查服务端了。

这里有个容易混的概念：并发数和每秒请求数是两回事。并发是同时压着的连接数，每秒请求数是由并发和单次响应时间共同决定的。报告里写结论时必须写清口径，否则同样的接口，两个人报出来的数字没法对比。

并发数

同一时刻压住的请求连接数量，是你设置的输入

吞吐量

单位时间内实际完成的请求数，是结果不是设定

拐点

响应时间或错误率突然变差的那一档并发，往往对应服务端某个资源打满

预热

正式统计前先跑一小轮，让连接池、缓存、JIT 等进入稳定状态，避免把冷启动数据算进去

压测时长也影响结论。短时间的高并发跑的是峰值能力，长时间低并发跑的是稳定性，两类目标要分开做，别用一次短跑同时下两个结论。

看哪几个指标，数值怎么判断好坏

报告出来先看四类指标：平均响应时间、分位值、错误率、吞吐量。只看平均值是最常见的误判来源——少数长尾慢请求会被大量快请求拉平，平均值看着漂亮，用户体验却很差。分位值更能反映真实体感，尤其是高并发下的尾部表现。

错误码要分开看：超时、限流、服务端错误含义完全不同。出现限流类错误，往往说明瓶颈在被压服务的调用配额，而不是代码本身。这类配额的口径跟厂商有关，具体档位到 /official-api 和你所用厂商的页面核对，不要凭记忆设目标值。

结果不理想时按这个顺序排查

1. 先排除压测机自己看本机 CPU、连接数、网络出口是否已经打满。压测机先撑不住时，压出来的曲线是假的，先换机器或降低单机并发再复测。
2. 再看网络链路跨地区访问、走代理都会抬高延迟。本地直连得到的结论和经网关转发的结论不能混在一起用，测试时固定同一种链路。
3. 再定位服务端数据库慢查询、锁竞争、下游依赖超时是高频原因。可以按 /guides/api-timeout-tuning 里的超时分层思路，把总耗时逐段拆开量，看时间花在哪一段。
4. 最后看限流与退避层出现限流类错误时，说明已经压过配额，这是个设计取舍问题而不是 bug。参考 /guides/429-concurrency-backoff 里的排队与退避做法，决定是提配额还是改客户端策略。

哪些情况下这套结论别直接当真

压测结论有明确的适用边界，越过边界就会得出误导性的容量判断。下面几种情况，结果只能当相对参考，不能直接推算上线容量。

• 测试环境的机器规格、数据量、缓存命中率和线上不一致时，压测只反映相对趋势，不能拿来乘系数推算线上的承载能力
• 接口强依赖第三方服务或大模型中转服务时，真正的瓶颈在外部，你在站内看到的只是端到端结果，改进空间有限
• 一次短压代表不了高峰持续负载，容量评估要按天或按周复测，观察不同时段的波动
• 测试账号和数据量比线上小很多时，数据库层的表现会偏乐观，这类差异要在结论里写明

把上面这些做完，一次压测才算完整。真正有价值的部分往往不是那个最大的并发数字，而是拐点出现在哪、瓶颈落在哪一层、以及下次改完接口后能不能复现同样的曲线。