并发用户数与 TPS 之间的关系 | 系统吞吐量、TPS（QPS）、用户并发量、性能测试概念和公式

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之间的关系》

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

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

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

系统吞吐量、TPS（QPS）、用户并发量、性能测试概念和公式

PS：下面是性能测试的主要概念和计算公式，记录下：

一．系统吞度量要素：

  一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。

系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间

        QPS（TPS）：每秒钟request/事务 数量

        并发数： 系统同时处理的request/事务数

        响应时间：  通常取平均响应时间

（不少人常常会把并发数和TPS理解混淆）

理解了上面三个要素的意义以后，就能推算出它们之间的关系：
QPS（TPS）= 并发数/平均响应时间    或者   并发数 = QPS*平均响应时间
        一个典型的上班签到系统，早上8点上班，7点半到8点的30分钟的时间里用户会登陆签到系统进行签到。公司员工为1000人，平均每一个员上登陆签到系统的时长为5分钟。能够用下面的方法计算。
QPS = 1000/(30*60) 事务/秒
平均响应时间为 = 5*60  秒
并发数= QPS*平均响应时间 = 1000/(30*60) *(5*60)=166.7

        一个系统吞吐量一般由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达 到系统最高值，系统的吞吐量就上不去了，若是压力继续增大，系统的吞吐量反而会降低，缘由是系统超负荷工做，上下文切换、内存等等其它消耗致使系统性能下 降。

决定系统响应时间要素

咱们作项目要排计划，能够多人同时并发作多项任务，也能够一我的或者多我的串行工做，始终会有一条关键路径，这条路径就是项目的工期。

系统一次调用的响应时间跟项目计划同样，也有一条关键路径，这个关键路径是就是系统影响时间；

关键路径是有CPU运算、IO、外部系统响应等等组成。

二．系统吞吐量评估：

咱们在作系统设计的时候就须要考虑CPU运算、IO、外部系统响应因素形成的影响以及对系统性能的初步预估。

而一般境况下，咱们面对需求，咱们评估出来的出来QPS、并发数以外，还有另一个维度：日PV。

经过观察系统的访问日志发现，在用户量很大的状况下，各个时间周期内的同一时间段的访问流量几乎同样。好比工做日的天天早上。只要能拿到日流量图和QPS咱们就能够推算日流量。

一般的技术方法：

        1. 找出系统的最高TPS和日PV，这两个要素有相对比较稳定的关系（除了放假、季节性因素影响以外）

        2. 经过压力测试或者经验预估，得出最高TPS，而后跟进1的关系，计算出系统最高的日吞吐量。B2B中文和淘宝面对的客户群不同，这两个客户群的网络行为不该用，他们之间的TPS和PV关系比例也不同。

A)淘宝

淘宝流量图：

淘宝的TPS和PV之间的关系一般为  最高TPS：PV大约为 1 : 11*3600 （至关于按最高TPS访问11个小时，这个是商品详情的场景，不一样的应用场景会有一些不一样）

B) B2B中文站

B2B的TPS和PV之间的关系不一样的系统不一样的应用场景比例变化比较大，粗略估计在1 : 8个小时左右的关系（09年对offerdetail的流量分析数据）。旺铺和offerdetail这两个比例相差很大，多是由于爬虫暂的比例较高的缘由致使。

在淘宝环境下，假设咱们压力测试出的TPS为100，那么这个系统的日吞吐量=100*11*3600=396万

这个是在简单（单一url）的状况下，有些页面，一个页面有多个request，系统的实际吞吐量还要小。

不管有无思考时间（T_think），测试所得的TPS值和并发虚拟用户数(U_concurrent)、Loadrunner读取的交易响应时间（T_response）之间有如下关系（稳定运行状况下）：
TPS=U_concurrent / (T_response+T_think)。

并发数、QPS、平均响应时间三者之间关系

   上图横坐标是并发用户数。绿线是CPU使用率；紫线是吞吐量，即QPS；蓝线是时延。
    开始，系统只有一个用户，CPU工做确定是不饱合的。一方面该服务器可能有多个cpu，可是只处理单个进程，另外一方面，在处理一个进程中，有些阶段多是 IO阶段，这个时候会形成CPU等待，可是有没有其余请 求进程能够被处理）。随着并发用户数的增长，CPU利用率上升，QPS相应也增长（公式为QPS=并发用户数/平均响应时间。）随着并发用户数的增长，平 均响应时间也在增长，并且平均响应时间的增长是一个指数增长曲线。而当并发数增长到很大时，每秒钟都会有不少请求须要处理，会形成进程（线程）频繁切换， 反正真正用于处理请求的时间变少，每秒可以处 理的请求数反而变少，同时用户的请求等待时间也会变大，甚至超过用户的心理底线。

来源：http://www.cnblogs.com/jackei/

软件性能测试的基本概念和计算公式

1、软件性能的关注点

对一个软件作性能测试时须要关注那些性能呢？

咱们想一想在软件设计、部署、使用、维护中一共有哪些角色的参与，而后再考虑这些角色各自关注的性能点是什么，做为一个软件性能测试工程师，咱们又该关注什么？

首先，开发软件的目的是为了让用户使用，咱们先站在用户的角度分析一下，用户须要关注哪些性能。

对于用户来讲，当点击一个按钮、连接或发出一条指令开始，到系统把结果已用户感知的形式展示出来为止，这个过程所消耗的时间是用户对这个软件性能的直观印 象。也就是咱们所说的响应时间，当相应时间较小时，用户体验是很好的，固然用户体验的响应时间包括我的主观因素和客观响应时间，在设计软件时，咱们就须要 考虑到如何更好地结合这两部分达到用户最佳的体验。如：用户在大数据量查询时，咱们能够将先提取出来的数据展现给用户，在用户看的过程当中继续进行数据检 索，这时用户并不知道咱们后台在作什么。

用户关注的是用户操做的相应时间。

其次，咱们站在管理员的角度考虑须要关注的性能点。

一、 相应时间
二、 服务器资源使用状况是否合理
三、 应用服务器和数据库资源使用是否合理
四、 系统可否实现扩展
五、 系统最多支持多少用户访问、系统最大业务处理量是多少
六、 系统性能可能存在的瓶颈在哪里
七、 更换那些设备能够提升性能
八、 系统可否支持7×24小时的业务访问

再次，站在开发（设计）人员角度去考虑。

一、 架构设计是否合理
二、 数据库设计是否合理
三、 代码是否存在性能方面的问题
四、 系统中是否有不合理的内存使用方式
五、 系统中是否存在不合理的线程同步方式
六、 系统中是否存在不合理的资源竞争

那么站在性能测试工程师的角度，咱们要关注什么呢？

一句话，咱们要关注以上全部的性能点。

2、软件性能的几个主要术语

一、响应时间：对请求做出响应所须要的时间

网络传输时间：N1+N2+N3+N4

应用服务器处理时间：A1+A3

数据库服务器处理时间：A2

响应时间=N1+N2+N3+N4+A1+A3+A2

二、并发用户数的计算公式

系统用户数：系统额定的用户数量，如一个OA系统，可能使用该系统的用户总数是5000个，那么这个数量，就是系统用户数。

同时在线用户数：在必定的时间范围内，最大的同时在线用户数量。
同时在线用户数=每秒请求数RPS（吞吐量）+并发链接数+平均用户思考时间

平均并发用户数的计算：C=nL / T

其中C是平均的并发用户数，n是平均天天访问用户数（login session），L是一天内用户从登陆到退出的平均时间（login session的平均时间），T是考察时间长度（一天内多长时间有用户使用系统）

并发用户数峰值计算：C^约等于C + 3*根号C

其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论。

三、吞吐量的计算公式

指单位时间内系统处理用户的请求数

从业务角度看，吞吐量能够用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量

从网络角度看，吞吐量能够用：字节/秒来衡量

对于交互式应用来讲，吞吐量指标反映的是服务器承受的压力，他可以说明系统的负载能力

以不一样方式表达的吞吐量能够说明不一样层次的问题，例如，以字节数/秒方式能够表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈；已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。

当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在必定的联系，能够采用如下公式计算：F=VU * R /

其中F为吞吐量，VU表示虚拟用户个数，R表示每一个虚拟用户发出的请求数，T表示性能测试所用的时间

四、性能计数器

是描述服务器或操做系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的做用，尤为是在分析通通可扩展性、进行新能瓶颈定位时有着很是关键的做用。

资源利用率：指系统各类资源的使用状况，如cpu占用率为68%，内存占用率为55%，通常使用“资源实际使用/总的资源可用量”造成资源利用率。

五、思考时间的计算公式

Think Time，从业务角度来看，这个时间指用户进行操做时每一个请求之间的时间间隔，而在作新能测试时，为了模拟这样的时间间隔，引入了思考时间这个概念，来更加真实的模拟用户的操做。

在吞吐量这个公式中F=VU * R / T说明吞吐量F是VU数量、每一个用户发出的请求数R和时间T的函数，而其中的R又能够用时间T和用户思考时间TS来计算：R = T / TS

下面给出一个计算思考时间的通常步骤：

A、首先计算出系统的并发用户数

C=nL / T F=R×C

B、统计出系统平均的吞吐量

F=VU * R / T R×C = VU * R / T

C、统计出平均每一个用户发出的请求数量

R=u*C*T/VU

D、根据公式计算出思考时间

TS=T/R