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

怼烎@ 2022-03-06 13:40 488阅读 0赞

# [性能测试中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= ![tps.png][]

## 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)更能让客户接受。

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;">方向</td> 
 <td style="vertical-align:top;">对比项</td> 
 <td style="vertical-align:top;">Loadrunner</td> 
 <td style="vertical-align:top;">PTS</td> 
 <td style="vertical-align:top;">备注</td> 
 </tr> 
 <tr> 
 <td> 基础设施 </td> 
 <td style="vertical-align:top;">被测系统软硬件环境需要额外购买？</td> 
 <td style="vertical-align:top;">需要</td> 
 <td style="vertical-align:top;">不需要</td> 
 <td style="vertical-align:top;">基础设施软硬件由阿里云提供，只需要购买服务</td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;">压力机环境需要额外购买？</td> 
 <td style="vertical-align:top;">需要</td> 
 <td style="vertical-align:top;">不需要</td> 
 <td style="vertical-align:top;">基础设施软硬件由PTS提供，只需要购买服务</td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 费用 </td> 
 <td style="vertical-align:top;">费用</td> 
 <td style="vertical-align:top;">非常贵</td> 
 <td style="vertical-align:top;">便宜，按需收费</td> 
 <td style="vertical-align:top;">商业化工具License非常贵</td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 功能 </td> 
 <td style="vertical-align:top;">功能</td> 
 <td style="vertical-align:top;">强大</td> 
 <td style="vertical-align:top;">较强大</td> 
 <td style="vertical-align:top;">LR很多功能基本上用不到，没必要大马拉小车</td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 易用性 </td> 
 <td style="vertical-align:top;">操作、学习等</td> 
 <td style="vertical-align:top;">困难</td> 
 <td style="vertical-align:top;">容易</td> 
 <td style="vertical-align:top;">LR不易上手</td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 稳定性 </td> 
 <td style="vertical-align:top;">系统稳定性</td> 
 <td style="vertical-align:top;">较稳定</td> 
 <td style="vertical-align:top;">非常稳定</td> 
 <td style="vertical-align:top;">LR压测过程中经常出现莫名其妙错误</td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 场景模拟 </td> 
 <td style="vertical-align:top;">场景模拟条件</td> 
 <td style="vertical-align:top;">较真实</td> 
 <td style="vertical-align:top;">非常真实</td> 
 <td style="vertical-align:top;">PTS分布在全国各地的分布式集群可以真实模拟出现实场景，而LR不太容易模拟，即使可以的话，控制机和压力机通信经常掉线</td> 
 </tr> 
 </tbody> 
</table>

## 9.  总结 ##

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

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

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

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

--------------------

# [性能测试中如何确定并发用户数][TPS] #

> **并发用户数**：**是指现实系统中操作业务的用户，在性能测试工具中，一般称为虚拟用户数(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可以帮助开发者通过分布式并发压力测试，模拟指定区域和指定数量的用户同时访问，提前预知网站承载力。这就是云计算给我们带来的便利。

[TPS]: https://blog.csdn.net/m0_37268841/article/details/88655188
[tps.png]: http://static.codeceo.com/images/2014/10/tps.png
[PTS]: http://www.aliyun.com/product/pts