6. 性能测试中tps和qps的概念是什么

做压测时最常卡住的两件事：一是报表上到底该写 TPS 还是 QPS，二是数值报出来了却没人认。这篇不堆公式，先把两个词的口径对齐，再给一套选出指标、排除干扰、写进结果的步骤，最后说清哪些场景下这套算法不适用。

做压测最常卡住的两件事：一是报表上到底该写 TPS 还是 QPS，二是数值报出来了却没人认。这篇不堆公式，先把两个词的口径对齐，再给一套选出指标、排除干扰、写进结果的步骤，最后说清哪些场景下这套算法不适用。

读之前先记住一个立场：这两个词都不是「对」或「错」，只是计的东西不一样。选错了不代表数据假的，但会让对面的人按另一套逻辑来理解你的结论，沟通成本比重新压一遍还高。所以你不需要背定义，你需要的是「我这业务该报哪个、报的时候要附什么说明」。

先把两个词的字面意思拆开

QPS 看的是查询类请求的频次，TPS 看的是完整事务的吞吐，两者都写作「每秒多少次」，但计的东西不同。一个事务可能包含多次请求，所以同一个系统用两种口径量，数值天然对不上，这不是谁测错了。

QPS

每秒被处理的查询请求数，通常按接口或请求级别统计，一个请求算一次

TPS

每秒被完整走完的事务数，一个事务可能跨多个接口、多步操作，全部成功才算一次

事务

你自己定义的业务最小完整单元，比如「提交一次订单」而不是「调了一次下单接口」

判断依据是业务单位：用户点一次按钮触发了几个接口，那几个接口合起来才算一次事务。如果你按接口数去报 TPS，那报出来的其实是接口层面的吞吐，挂上事务的名字会误导做容量规划的人。

• 先写出一次典型用户操作触发了哪些后端请求，把清单列出来
• 再标出哪些请求是必须全部成功才算完成，哪些失败了不影响主流程
• 按这份清单决定事务边界，边界一旦定下，压测脚本和统计口径都要跟着它走

为什么两份压测报告的数字对不上

两边团队各压一遍，数字差一截，最常见的不是工具问题，而是口径问题。下面这张表把常见的分歧点列出来，沟通前先逐条对一遍，比争论谁的脚本更准有用得多。

想快速定位差异，最快的方法不是比数值大小，而是让对方把上面这几项逐条说一遍。多数情况下你会在第二行或第三行就找到原因，剩下的事就是统一口径重测一次。

怎么判断你的项目该报哪个

选指标不靠习惯，靠业务形态。读多写少的查询接口，报 QPS 更贴近真实负载；下单、支付、审批这类多步流程，报 TPS 才说得通，因为用户感知的是「这件事办完了没有」，不是「某个接口回了没有」。

• 单接口、无状态、纯查询：报 QPS，并注明是接口级还是集群级
• 多步流程、有状态、有中间失败分支：报 TPS，写清事务包含哪几步
• 对外提供 API 并要标注调用限制：通常按 QPS 沟通，因为调用方按请求数计
• 内部做容量规划和扩容决策：通常看 TPS，因为要换算成机器和连接数
• 实在拿不准：两个都写，并在旁边注明各自口径，比只写一个数被追问要好

如果对方是外部合作方，先问一句「你们说的每秒多少次，是按请求算还是按事务算」，这一句能省掉后面一整轮返工。对外的接口文档通常写 QPS 限制，对内的容量规划通常看 TPS，这两套话术混用是常态，别默认对方和你想的是同一套。

一次能站得住脚的测量流程

流程的价值在于让别人能复现你的结论。下面这几步按顺序走，每一步都留下可查的记录，报告才立得住。

1. 定业务单位写清一次事务包含哪几个请求、成功判定条件是什么、哪一步失败算整笔失败。把这份定义放进报告开头。
2. 小并发验证功能先用很低并发跑通，确认数据写对了、返回符合预期。功能不对的时候压出来的性能数字没有意义。
3. 逐级加并发每级记录每秒次数、平均响应时间、错误率。注意别只记一个峰值，峰值旁边往往就是错误率开始抬头的位置。
4. 取稳定区间去掉预热阶段和明显受外部干扰的时段，用中间那段平稳的数据作为结论依据。
5. 重复至少两轮同一条件跑两轮，两轮差异大就先查环境，别急着下结论。差异小才说明这个数稳定可引用。

每一步都要留痕：脚本版本、参数、环境说明、取数区间。别人复现不出来的时候，争论的就不是数据本身，而是你到底怎么测的。

哪些干扰会让你量出来的数不可信

数字不可信，很多时候不是被测服务的问题，是测量过程本身出了问题。下面这几类干扰最常见，出现任意一条，结论都应该打上问号。

• 压测机自身打满，瓶颈在客户端而不是被测服务，这时数字反映的是你的测试机性能
• 连接池、限流阈值、缓存命中率在不同轮次不一致，数值波动会被误读成系统变化
• 被测服务背后共享数据库或第三方接口，别人同时在用，你的结果掺了别人的量
• 网络路径不同，同一套脚本在本地和线上跑出的结果本来就不该直接比
• 压测脚本里混了业务逻辑计算或数据构造，真正吃掉的资源在脚本侧而不在服务侧

什么时候这套判断不适用：如果你压的是纯内存计算、没有外部依赖的独立服务，且压测机和被测服务资源隔离清楚，那么上面前三条基本可以排除，重点看脚本本身有没有成为瓶颈就行。

并发数、响应时间和每秒次数三者的关系

粗略关系是并发数约等于每秒次数乘平均响应时间，用它做量级自查，别当成精确公式。比如有人报出一个很高的每秒次数，同时响应时间又很长，把两个数乘一下得到的并发数远超他实际开的并发，那这个数大概率口径有问题。

响应时间变长时，每秒次数不一定同比例下降，要看服务内部是排队还是并行处理。知道这三者的联动关系，就能在评审会上快速判断一个报出来的数是不是明显不合常理，而不是等别人来质疑。

把口径写进结论，别只留一个数字

一个数字单独放出来是没法被引用的。想让别人认，就得把口径固定下来，跟数字一起写进结论。下面这几项是必须写清的固定要素，缺一项后面就可能被追问一轮。

• 统计对象：是接口级还是事务级，事务边界是什么
• 成功定义：只算成功返回，还是把超时和失败也计入
• 压测时长与并发级数：从多少并发加到多少并发
• 取数区间：从稳定段的哪一段到哪里
• 环境说明：机器规格、依赖服务、是否有其他人同时使用
• 观察时间：数字会随环境和版本变化，引用时要写明是什么时候观察到的

如果你要把性能数据换算成调用成本，思路是把每秒请求数和单次请求的用量乘起来再对价，量级参考站内 Token 单价换算工具；各家的价格和额度本身会调整，具体数字到站内的价格追踪页面按当期核对，别把某次看到的数直接写进长期文档。

能被复现的数字才叫结论，不能被复现的只能叫一次观测。