我也想问这个问题！+1
个人理解：
1、这个图里的总体吞吐量，实际计算公式是总样本数/总压测时长，因此你会发现和上面每个接口吞吐量加起来的和差不多。
2、对于 “系统能处理的吞吐量” ，我觉得需要加上前置条件，就是 “在存在 xxx 、xxx... 接口调用，且比例为 xx:xx:xx... 时，系统可处理的总吞吐量”。原因很简单，你的接口调用个数（调 3 个不同的接口改为调 4 个不同的接口），或者比例一旦变化，这个吞吐量的数值可能就会变了，所以没有这个前置条件，可以有无数个 “系统能处理的吞吐量” ，且都是真实压测采集到的数据。
3、一般性能测试，关注的是典型业务场景下性能是否可以抗住，所以主要是通过模拟典型业务场景下的接口调用比例去调用接口，观察此时的性能是否达标（吞吐量 + 响应时间）。此时的总体吞吐量一般会简称为 “xx 场景下的系统总体吞吐量” 。从你图上看，样本数各个接口基本是 1:1 的，感觉不像是真实业务场景（最简单的，登录和申请办证的比例一定是 1：1 么？个人经验应该不会）。如果场景本身就和现实情况差异很大，那这个场景下的性能数据就没啥意义了。
陈恒捷
回复
谢谢回复，关于第三点是因为后面接口必须登录获取 token 才能执行，所以在场景设计时就是每次都需要登录，另外我还想问下，TPS 达到多少才合适，是否有一个参考
张
回复
1、登录这个 token 有效期多久？是否可以预先准备，压测时直接使用，而不是压测时才获取？
2、TPS 达到多少合适，要看你业务峰值压力预估情况，没有通用参考值。如果是已经上线有线上数据的，可以根据线上数据以及业务预估业务峰值（比如搞活动）会比日常的峰值多多少倍，来预估；如果未上线，那就要自己结合业务情况评估了，最好评估后拉上开发、产品一起确认，达成共识。举个例子，假设预估业务高峰期会达到一小时 1000 人左右进行驾驶证申请，那驾驶证申请接口的 TPS 要求就是 1000/(60*60)=0.27 。
PS：不要盲目用什么二八原则按天估算，这就是纯 yy 的。实际日常业务高峰期情况怎样，各个接口负荷情况如何，找运维拉个单日各接口调用量的图表看更靠谱。
陈恒捷
回复
谢谢回复，非常感谢
1、首先这个 token 有效期是很久的，但是没法预先准备，这是第三方给的，我这边使用的一个模拟的登录接口，token 不会保存在数据库，而是在 Redis，我也没法保存和相关用户对应上。
2、TPS 在 0.27 是否过低，我们目前定义的 TPS 要达到 300（非查询类接口）
张
回复
1、为啥无法预先准备呢？你先跑一遍模拟登陆，把 token 拿到，然后再把这些 token 用到后面接口就可以？你原来用登录接口也是分 登录获取 token 和 其它接口使用 token 两步吧，现在只是把第一步拆出来而已。
2、我只是举个例子。如果你已经确认了 TPS 要 300，那就按 300 就好。
小老弟，你这是混合容量测试吧?这场景设计的很不真实啊。最大稳定性 tps 拿到了吗?业务比例有没有?存量数据够不够?
稳定的环境 + 合理的数据 + 真实的场景=有效的结果
缺了任何一个前提条件，结果都是假的