并发虚拟用户、RPS、TPS的解读

在作性能测试的时候，传统方式都是用并发虚拟用户数来衡量系统的性能（站在客户端视角），通常适用于一些网页站点好比首页、H5 的压测；而 RPS（Requests per second）模式主要是为了方便直接衡量系统的吞吐能力-TPS（Transaction Per Second, 每秒事务数）而设计的（站在服务端视角），按照被压测端须要达到TPS等量设置相应的RPS，应用场景主要是一些动态的接口API，好比登录、提交订单等等。

VU（虚拟用户）和TPS之间也有其逻辑关系。具体请看下方的说明。

术语定义

• 并发用户数：简称VU ,指的是现实系统中操做业务的用户，在性能测试工具中，通常称为虚拟用户数(Virutal User)，注意并发用户数跟注册用户数、在线用户数有很大差异的，并发用户数必定会对服务器产生压力的，而在线用户数只是 ”挂” 在系统上，对服务器不产生压力，注册用户数通常指的是数据库中存在的用户数。
• 处理能力：简称TPS, 每秒事务数, 是衡量系统性能的一个很是重要的指标。
• 响应时间：简称RT,指的是业务从客户端发起到客户端接受的时间。

VU 和 TPS 换算

• 简单例子：在术语中解释了TPS是每秒事务数，可是事务时要靠虚拟用户作出来的，假如1个虚拟用户在1秒内完成1笔事务，那么TPS明显就是1；若是某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务，TPS就是1000了；若是某笔业务响应时间是1s,那么1个用户在1秒内只能完成1笔事务，要想达到1000TPS，至少须要1000个用户；所以能够说1个用户能够产生1000TPS，1000个用户也能够产生1000TPS，无非是看响应时间快慢。

• 复杂公式：试想一下复杂场景，多个脚本，每一个脚本里面定义了多个事务（例如一个脚本里面有100个请求，咱们把这100个连续请求叫作Action,只有第10个请求，第20个请求分别定义了事务10和事务20）具体公式以下：

  符号表明意义：

  Vui表示的是第i个脚本使用的并发用户数

  Rtj表示的是第i个脚本第j个事务花费的时间，此时间会影响整个Action时间

  Rti表示的是第i个脚本一次完成全部操做的时间，即Action时间

  n 表示的是第n个脚本

  m 表示的是每一个脚本中m个事务

  那么第j个事务的 TPS = Vui/Rti

  总的TPS=

 如何获取 VU 和 TPS

• 并发用户数(VU)获取方式：

已有系统：可选取高峰时刻，在必定时间内使用系统的人数，这些人数可认为是在线用户数，并发用户数能够取10%，例如在半个小时内，使用系统的用户数为10万，那么取10%（即1万）做为并发用户数基本就够了。

新系统：没有历史数据做参考，建议经过业务部门进行评估。

• TPS获取方式：

已有系统：可选取高峰时刻，在必定时间内（如3-10分钟），获取系统总业务量，计算单位时间（秒）内完成的笔数，乘以2-5倍做为峰值的TPS，例如峰值3分钟内处理订单18万笔，平均TPS是1000，峰值TPS能够是2000-5000。

新系统：没有历史数据做参考，建议经过业务部门进行评估。

如何评价系统的性能

针对服务器端的性能，以TPS为主来衡量系统的性能，并发用户数为辅来衡量系统的性能，若是必需要用并发用户数来衡量的话，须要一个前提，那就是交易在多长时间内完成，由于在系统负载不高的状况下，将思考时间(思考时间的值等于交易响应时间)加到串联链路中，并发用户数基本能够增长一倍，所以用并发用户数来衡量系统的性能没太大的意义。一样的，若是系统间的吞吐能力差异很大，那么一样的并发下TPS差距也会很大。

性能测试策略

作性能测试须要一套标准化流程及测试策略。在作负载测试的时候，传统方式通常都是按照梯度施压的方式去加用户数，避免在没有预估的状况下，一次加几万个用户，致使交易失败率很是高，响应时间很是长，已经超过了使用者忍受范围内；较为适合互联网分布式架构的方式，也是阿里的最佳实践是用TPS模式（吞吐量模式）+设置起始和目标最大量级，而后根据系统表现灵活的手工实时调速，效率更高，服务端吞吐能力的衡量一步到位。

总结

• 系统的性能由TPS决定，跟并发用户数没有多大关系。
• 系统的最大TPS是必定的（在一个范围内），但并发用户数不必定，能够调整。
• 建议性能测试的时候，不要设置过长的思考时间，以最坏的状况下对服务器施压。
• 通常状况下，大型系统（业务量大、机器多）作压力测试，10000～50000个用户并发，中小型系统作压力测试，5000个用户并发比较常见。