TPS模式（吞吐量模式）是一种更好的方式衡量服务端系统的能力。
基本概念：
并发用户数：简称VU ,指的是现实系统中操作业务的用户，在性能测试工具中，一般称为虚拟用户数(Virutal User)，注意并发用户数跟注册用户数、在线用户数有很大差别的，并发用户数一定会对服务器产生压力的，而在线用户数只是 ”挂” 在系统上，对服务器不产生压力，注册用户数一般指的是数据库中存在的用户数。
处理能力: 简称TPS, 每秒事务数, 是衡量系统性能的一个非常重要的指标。
响应时间：简称RT,指的是业务从客户端发起到客户端接受的时间。
VU与TPS换算：
假如1个虚拟用户在1秒内完成1笔事务，那么TPS明显就是1；如果某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务，TPS就是1000了；如果某笔业务响应时间是1s,那么1个用户在1秒内只能完成1笔事务，要想达到1000TPS，至少需要1000个用户；因此可以说1个用户可以产生1000TPS，1000个用户也可以产生1000TPS，无非是看响应时间快慢。比如 1000 并发，RT 平均从 1 秒变长到 2 秒，那么 TPS 也从 1000 下降到了 500。
获取VU：
新系统：没有历史数据作参考，只能通过业务部门进行评估。
旧系统：对于已经上线的系统，可以选取高峰时刻，在一定时间内使用系统的人数，这些人数认为属于在线用户数，并发用户数取10%就可以了，例如在半个小时内，使用系统的用户数为10000，那么取10%作为并发用户数基本就够了。
获取TPS：
新系统：没有历史数据作参考，只能通过业务部门进行评估。
旧系统：对于已经上线的系统，可以选取高峰时刻，在5分钟或10分钟内，获取系统每笔交易的业务量和总业务量，按照单位时间内完成的笔数计算出TPS，即业务笔数/单位时间。
衡量服务端性能：
服务器端的性能，以TPS为主来衡量系统的性能，并发用户数为辅来衡量系统的性能，在系统负载不高的情况下，将思考时间(思考时间的值等于交易响应时间)加到串联链路中，并发用户数基本可以增加一倍，因此用并发用户数来衡量系统的性能没太大的意义。如果系统间的吞吐能力差别很大，那么同样的并发下TPS差距也会很大。
性能测试策略：
用TPS模式（吞吐量模式）+设置起始和目标最大量级，然后根据系统表现灵活的手工实时调速。
TPS 模式以吞吐量作为目标，比如 1000 TPS 表示一秒内发出 1000 个请求，TPS 模式下的虚拟用户数 = TPS x RT（秒）。例如用户设置 TPS 为 100，而被压接口的 RT 为 0.1 秒，此时并发量为 10；若被压接口 RT 为 2 秒，则并发量为 200。当被压测的服务异常时，会出现大量的 RT 变高甚至是请求失败超时，这个时候并发会越来越高而且在 API 的超时时间内累积，此时需要及时停止压测。
总结：
系统的性能由TPS决定，跟并发用户数没有多大关系。
系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。
建议性能测试的时候，不要设置过长的思考时间，以最坏的情况下对服务器施压。