并发用户数与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)更能让客户接受。

方向对比项LoadrunnerPTS备注

基础设施

被测系统软硬件环境需要额外购买?需要不需要基础设施软硬件由阿里云提供,只需要购买服务
压力机环境需要额外购买?需要不需要基础设施软硬件由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可以帮助开发者通过分布式并发压力测试,模拟指定区域和指定数量的用户同时访问,提前预知网站承载力。这就是云计算给我们带来的便利。

阅读更多
换一批

没有更多推荐了,返回首页