性能测试中TPS和并发用户数

并发用户数与TPS之间的关系

 

 

1.  背景

在作性能测试的时候，不少人都用并发用户数来衡量系统的性能，以为系统能支撑的并发用户数越多，系统的性能就越好；对TPS不是很是理解，也根本不知道它们之间的关系，所以很是有必要进行解释。

2.  术语定义

Ø  并发用户数：指的是现实系统中操做业务的用户，在性能测试工具中，通常称为虚拟用户数(Virutal User)，注意并发用户数跟注册用户数、在线用户数有很大差异的，并发用户数必定会对服务器产生压力的，而在线用户数只是 ”挂” 在系统上，对服务器 不产生压力，注册用户数通常指的是数据库中存在的用户数。

Ø  TPS：Transaction Per Second, 每秒事务数, 是衡量系统性能的一个很是重要的指标，

3.  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= 

4.  如何获取Vu和TPS

Ø  并发用户数(Vu)获取

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

旧系统：对于已经上线的系统，能够选取高峰时刻，在必定时间内使用系统的人数，这些人数认为属于在线用户数，并发用户数取10%就能够了，例如在半个小时内，使用系统的用户数为10000，那么取10%做为并发用户数基本就够了。

Ø  TPS获取

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

旧系统：对于已经上线的系统，能够选取高峰时刻，在5分钟或10分钟内，获取系统每笔交易的业务量和总业务量，按照单位时间内完成的笔数计算出TPS，即业务笔数/单位时间（5*60或10*60）

5.  如何评价系统的性能

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

6.  相关案例

经过大量性能测试咱们发现不须要用上万的用户并发去进行测试，只要系统处理业务时间足够快，几百个用户甚至几十个用户就能够达到目的。另外咨询不少专家作过的性能测试项目，基本都没有超过5000用户并发。

所以对于大型系统、业务量很是高、硬件配置足够多的状况下，5000用户并发就足够了；对于中小型系统，1000用户并发就足够了。

7.  性能测试策略

作性能测试须要一套标准化流程及测试策略，并发用户数只是指标考虑的一个，在作负载测试的时候，通常都是按照梯度施压的方式去加用户数，而不是在没 有预估的状况下，一次加几万个用户，，交易失败率很是高，响应时间很是长，已经超过了使用者忍受范围内，这样作没有多大的意义，这就比如“有多少钱能够干 多少事”同样，须要选择相关的策略。

8.  Loadrunner VS PTS

从下图对比项能够看出，PTS比Loadrunner(LR)更能让客户接受。

方向	对比项	Loadrunner	PTS	备注
基础设施	被测系统软硬件环境须要额外购买？	须要	不须要	基础设施软硬件由阿里云提供，只须要购买服务
	压力机环境须要额外购买？	须要	不须要	基础设施软硬件由PTS提供，只须要购买服务
费用	费用	很是贵	便宜，按需收费	商业化工具License很是贵
功能	功能	强大	较强大	LR不少功能基本上用不到，不必大马拉小车
易用性	操做、学习等	困难	容易	LR不易上手
稳定性	系统稳定性	较稳定	很是稳定	LR压测过程当中常常出现莫名其妙错误
场景模拟	场景模拟条件	较真实	很是真实	PTS分布在全国各地的分布式集群能够真实模拟出现实场景，而LR不太容易模拟，即便能够的话，控制机和压力机通讯常常掉线

9.  总结

Ø  系统的性能由TPS决定，跟并发用户数没有多大关系。在一样的TPS下，能够由不一样的用户数去压（经过加思考时间设置）。

Ø  系统的最大TPS是必定的（在一个范围内），但并发用户数不必定，能够调整。

Ø  建议性能测试的时候，不要设置过长的思考时间，以最坏的状况下对服务器施压。

Ø  通常状况下，大型系统（业务量大、机器多）作压力测试，5000个用户并发就够了，中小型系统作压力测试，1000个用户并发就足够了。

 

 

性能测试中如何肯定并发用户数

并发用户数：是指现实系统中操做业务的用户，在性能测试工具中，通常称为虚拟用户数(Virutal User)。

并发用户数和注册用户数、在线用户数的概念不一样，

并发用户数必定会对服务器产生压力的，

而在线用户数只是 ”挂” 在系统上，对服务器不产生压力，

注册用户数通常指的是数据库中存在的用户数。

 

TPS：Transaction Per Second, 每秒事务数, 是衡量系统性能的一个很是重要的指标。

        做者认为如今不少从业人员在作性能测试时，都错误的认为系统能支撑的并发用户数越多，系统的性能就越好。要理解这个问题，

        首先须要了解TPS和并发用户数之间的关系：

TPS就是每秒事务数，可是事务是基于虚拟用户数的，假如1个虚拟用户在1秒内完成1笔事务，那么TPS明显就是1；若是 某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务，TPS就是1000了；若是某笔业务响应时间是1s,那么1个用户在1秒内只能完 成1笔事务，要想达到1000TPS，至少须要1000个用户；所以能够说1个用户能够产生1000TPS，1000个用户也能够产生1000TPS，无 非是看响应时间快慢。

也就是说，在评定服务器的性能时，应该结合TPS和并发用户数，以TPS为主，并发用户数为辅来衡量系统的性能。若是必需要用并发用户数来衡量的 话，须要一个前提，那就是交易在多长时间内完成，由于在系统负载不高的状况下，将思考时间(思考时间的值等于交易响应时间)加到脚本中，并发用户数基本可 以增长一倍，所以用并发用户数来衡量系统的性能没太大的意义。

做者最后作了综述，他认为在性能测试时并不须要用上万的用户并发去进行测试，若是只须要保证系统处理业务时间足够快，几百个用户甚至几十个用户就可 以达到目的。据他了解，不少专家作过的性能测试项目基本都没有超过5000用户并发。所以对于大型系统、业务量很是高、硬件配置足够多的状况下，5000 用户并发就足够了；对于中小型系统，1000用户并发就足够了。

性能测试须要一套标准化流程及测试策略，在实际测试时咱们还须要考虑其它方面的问题，好比如何模拟成千上万来自不一样地区用户的访问场景、如何选用合适的测试软件。性能测试对一些小的团队来讲并不是易事，不过前段时间阿里云发布了性能测试服务PTS，PTS能够帮助开发者经过分布式并发压力测试，模拟指定区域和指定数量的用户同时访问，提早预知网站承载力。这就是云计算给咱们带来的便利。