性能测试 之并发用户数知多少

Posted 2023-04-18

参考技术A 一、经典公式1：

一般来说，利用以下经验公式进行估算系统的平均并发用户数和峰值数据

1）平均并发用户数为 C = nL/T

2）并发用户数峰值 C‘ = C + 3*根号C

C是平均并发用户数，n是login session的数量，L是login session的平均长度，T是值考察的时间长度

C’是并发用户数峰值

举例1，假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统日志从获得），对于一个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时之内会使用该系统。

那么，

平均并发用户数为：C = 400*4/8 = 200

并发用户数峰值为：C‘ = 200 + 3*根号200 = 243

举例2， 某公司为其170000名员工设计了一个薪酬系统，员工可进入该系统查询自己的薪酬信息，但并不是每个人都会用这个系统，假设只有50%的人会定期用该系统，这些人里面有70%是在每个月的最后一周使用一次该系统，且平均使用系统时间为5分钟。

则一个月最后一周的平均并发用户数为（朝九晚五）：

n = 170000*0.5*0.7/5 = 11900

C= 11900*5/60/8 = 124

二、通用公式2：

对绝大多数场景，我们用（用户总量/统计时间）*影响因子（一般为3）来进行估算并发量。

比如，以乘坐地铁为例子，每天乘坐人数为5万人次，每天早高峰是7到9点，晚高峰是6到7点，根据8/2原则，80%的乘客会在高峰期间乘坐地铁，则每秒到达地铁检票口的人数为50000*80%/（3*60*60）=3.7，约4人/S，考虑到安检，入口关闭等因素，实际堆积在检票口的人数肯定比这个要大，假定每个人需要3秒才能进站，那实际并发应为4人/s*3s=12，当然影响因子可以根据实际情况增大！

三、根据PV计算公式：

比如一个网站，每天的PV大概1000w，根据2/8原则，我们可以认为这1000w pv的80%是在一天的9个小时内完成的（人的精力有限），那么TPS为：

1000w*80%/(9*3600)=246.92个/s,取经验因子3，则并发量应为：

246.92*3=740

四、根据TPS估计：

公式为 C = (Think time + 1)*TPS

五、根据系统用户数计算：

并发用户数 = 系统最大在线用户数的8%到12%

性能测试四十五：性能测试策略

1、项目具体需求,及业务场景：关注真实用户会是怎样的一个业务场景，确定用户的用户习惯。

2、指标：响应时间在多少以内，并发数多少，tps多少，总tps多少，稳定性交易总量多少，事务成功率，交易波动范围，稳定运行时长，资源利用率，测哪些交易，哪些接口,测试哪些场景。

3、环境：生产环境服务器数量，测试环境服务器数量，按照资源配比得出测试指标。

4、协议：系统用什么协议进行通讯。

5、压力机数量：如果并发用户数太多，需要把压力发到不同的压力机，不然可能会存在压力机瓶颈问题，导致tps和响应时间抖动。

6、交易占比：分析线上日志得出tps占比。

7、系统架构：请求流经过哪些环节，压测时监控这些环节。

测试

1、基准：一个用户迭代100次，关注响应时间，事务成功率100%。

2、负载：10个用户跑10分钟，关注响应时间，事务成功率100%。

3、容量：估算一个总tps，根据公式计算出每个交易的pacing和vu，获取系统最大处理能力（最优容量），再令外测出三个梯度作为对比（两组小于最优容量，一组大于最优容量），四组容量VU等差，tps等差，对比每组容量实际占比和测试占比（越接近越能模拟真实场景），关注响应时间，总tps，tps，事务成功率，AP cpu利用率，DB cpu利用率，线程死锁，数据库死锁。

     其中响应时间应小于负载测试时间，总tps应约等于预估总tps（相差不超过10是正常的），每个交易的tps应接近预估总tps*占比，事务成功率100%，AP cpu小于60%，DB cpu小于80%。dump线程栈检测是否有线程死锁，查看数据库日志看是否有数据库死锁。

4、稳定性：采取最优容量的80%作为压力持续运行24小时，观察系统长时间运行的性能表现，关注响应时间，tps，总tps，事务成功率，交易总数，观察是否有内存溢出（堆溢出，栈溢出，持久代溢出），cpu利用率是否达标，mem是否不持续增长，是否能正常触发fullgc，gc时间，gc频率， fullgc时间，fullgc频率（重点关注，JVM调优就是为了减少fullgc频率）。

压测中遇到的性能问题及解决办法

一、测试过程中cpu过高

1、用vmstat实时监控cpu使用情况。很小的压力AP cpu却到了80%多，指标是不能超过60%。

2、分析是use cpu过高还是sys cpu过高，常见的是use cpu使用过高。

3、如果是sys cpu使用过高，先把消耗cpu最多的进程找出来（top命令），再找到该线程下消耗cpu过高的是哪几个线程，再把该线程转换成16进制，再用jstack命令来dump线程栈，看这个线程栈在调用什么东西导致use cpu过高。

二、内存溢出（堆溢出、栈溢出、持久代溢出）

1、堆内存溢出

1)稳定性压测一段时间后，LR报错，日志报java.lang.OutOfMemoryError.Java heap space。

2)用jmap -histo pid命令dump堆内存使用情况，查看堆内存排名前20个对象，看是否有自己应用程序的方法，从最高的查起，如果有则检查该方法是什么原因造成堆内存溢出。

3)如果前20里没有自己的方法，则用jmap -dump来dump堆内存，在用MAT分析dump下来的堆内存，分析导出内存溢出的方法。

4)如果应用程序的方法没有问题，则需要修改JVM参数，修改xms，xmx，调整堆内存参数，一般是增加堆内存。

2、栈内存溢出

1)稳定性压测一段时间后，LR报错，日志报Java.Lang.StackOverflowError。

2)修改jvm参数，将xss参数改大，增加栈内存。

3)栈溢出一定是做批量操作引起的，减少批处理数据量。

3、持久代溢出

1)稳定性压测一定时间后，日志报Java.Lang.OutOfMenoryError.PermGen Space。

2)这种原因是由于类、方法描述、字段描述、常量池、访问修饰符等一些静态变量太多，将持久代占满导致持久代溢出。

3)修改jvm配置，将XX:MaxPermSize=256参数调大。尽量减少静态变量。

三、线程死锁

1、容量测试压测一段时间后，LR报连接超时。

2、造成这种现象的原因很多，比如带宽不够，中间件线程池不够用，数据库连接池不够，连接数占满等都会造成连接不上而报超时错误。

3、jstack命令dump线程栈，搜索线程栈里有没有block，如果有的话就是线程死锁，找到死锁的线程，分析对应的代码。

四、数据库死锁

1、容量测试压测一段时间后，LR报连接超时。

2、造成这种现象的原因很多，比如带宽不够，中间件线程池不够用，数据库连接池不够，连接数占满等都会造成连接不上而报超时错误。

3、数据库日志中搜索block，能搜到block的话就是存在数据库死锁，找到日志，查看对应的sql，优化造成死锁的sql。

五、数据库连接池不释放

1、容量测试压测一段时间后，LR报连接超时。

2、造成这种现象的原因很多，比如带宽不够，中间件线程池不够用，数据库连接池不够，连接数占满等都会造成连接不上而报超时错误。

3、去数据库查看应用程序到数据库的连接有多少个（ show full processlist），假如应用程序里面配置的数据库连接为30，在数据库查看应用程序到数据库的连接也是30，则表示连接池占满了。将配置改成90试试，去数据库看如果连接到了90，则可以确定是数据库连接池不释放导致的。查看代码，数据库连接部分是不是有创建连接但是没有关闭连接的情况。基本就是这种情况导致的，修改代码即可。

六、TPS上不去

1、压力大的时候tps频繁抖动，导致总tps上不去。查看是否有fullgc（tail -f gc_mSrv1.log | grep full）。

2、pacing设置太小也会导致tps上不去，对抖动大的交易多增加点用户即可。

3、tps抖动，单压抖动大的交易，发现很平稳，这时怀疑是不是压力太大导致，所以发容量的时候把压力最大的那只交易分到其他压力机，然后发现tps不抖动了。注意：多台压力机只影响tps抖动，不会影响服务器的cpu。

4、看响应时间有没有超时，看用户数够不够。

七、服务器压力不均衡（相差1%-2%是正常的）

1、跑最优容量的时候，四台AP只有一台cpu超过60%，其他三台都在60%以下。

2、查看服务器是否有定时任务。

3、查看是否存在压力机瓶颈。

4、是否存在带宽瓶颈（局域网不存在此问题）。

5、查看部署的版本，配置是否一样。

6、可能别人也在用这些AP，因为同一台物理机上有很多虚拟机，因为别人先用，资源被别人先占了。

八、fullgc时间太长

1、跑容量和稳定性的时候，出现LR报请求超时错误，查看后台日志是fullgc了，看LR几点报的错和日志里fullgc的时间是否对应，fullgc会暂停整个应用程序，导致LR前端没响应，所以报错，这时可以减少old代内存，从而减少fullgc时间，减少fullgc时间LR就不会报错，让用户几乎感觉不到应用程序暂停。

2、四台AP轮流着full gc（部分server fullgc，其他server也会fullgc），这时可以制定策略让不同的server不同时fullgc，或者等夜间交易量少时写定时任务重启服务。

十、系统性能指标

1）业务指标：主要包括并发用户数、响应时间、处理能力。

指标	定义	简称	标准
交易响应时间	指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。	Response Time: RT	对于在线实时交易： 互联网企业：500毫秒以下，例如淘宝业务10毫秒左右。 金融企业：1秒以下为佳，部分复杂业务3秒以下。 保险企业：3秒以下为佳。 制造业：5秒以下为佳。 对于批量交易： 不同数据量结果是不一样的，大数据量的情况下，2小时内完成。
系统处理能力	指系统在利用系统硬件平台和软件平台进行信息处理的能力。 系统处理能力通过系统每秒钟能够处理的交易数量来评价，交易有两种理解：一是业务人员角度的一笔业务过程；二是系统角度的一次交易申请和响应过程。前者称为业务交易过程，后者称为事务。两种交易指标都可以评价应用系统的处理能力。一般建议与系统交易日志保持一致，以便于统计业务量或者交易量。	HPS（Hits Per Second） ：每秒点击次数，单位是次/秒。 TPS（Transaction per Second）：系统每秒处理交易数，单位是笔/秒。 QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒。 对于互联网业务中，如果某些业务有且仅有一个请求连接，那么TPS=QPS=HPS。 一般情况下，用TPS来衡量整个业务流程，用QPS来衡量接口查询次数，用HPS来表示对服务器点击请求。	无论TPS、QPS、HPS,此指标是衡量系统处理能力非常重要的指标，越大越好。
并发用户数	指在同一时刻内，登录系统并进行业务操作的用户数量。在测试中，采用虚拟用户来模拟现实中用户进行业务操作。	Virtual User: VU	一般情况下，性能测试是将系统处理能力容量测出来，而不是测试并发用户数，除了服务器长连接可能影响并发用户数外，系统处理能力不受并发用户数影响，可以用最小的用户数将系统处理能力容量测试出来，也可以用更多的用户将系统处理能力容量测试出来。
错误率	指系统在负载情况下，失败交易的概率。 错误率＝(失败交易数/交易总数)*100%。 稳定性较好的系统，其错误率应该由超时引起，即为超时率。	Failure Ratio: FR	不同系统对错误率的要求不同，但一般不超出千分之六，即成功率不低于99.4%。

 

2）资源指标：CPU资源利用率、内存利用率、磁盘I/O、网络I/O、内核参数(信号量、打开文件数)等。

指标	定义	简称	标准
CPU	中央处理器是一块超大规模的集成电路，是一台计算机的运算核心（Core）和控制核心（ Control Unit）。它的功能主要是解释计算机指令以及处理计算机软件中的数据。	Central Processing Unit：CPU	CPU指标主要指的CPU利用率，包括用户态(user)、系统态(sys)、等待态(wait)、空闲态(idle)。 CPU利用率要低于业界警戒值范围之内，即小于或者等于75%; CPU sys%小于或者等于30%,  CPU wait%小于或者等于5%。 CPU Load要小于CPU 核数。
内存	内存是计算机中重要的部件之一，它是与CPU进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的，因此内存的性能对计算机的影响非常大。	Memory就是内存的简称	现代的操作系统为了最大利用内存，在内存中存放了缓存，因此内存利用率100%并不代表内存有瓶颈，衡量系统内有有瓶颈主要靠SWAP（与虚拟内存交换）交换空间利用率，一般情况下，SWAP交换空间利用率要低于70%,太多的交换将会引起系统性能低下。
磁盘吞吐量	指在无磁盘故障的情况下单位时间内通过磁盘的数据量。	Disk Throughput	磁盘指标主要有每秒读写多少兆，磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的的重要依据，一般情况下，磁盘繁忙率要低于70%。
网络吞吐量	指在无网络故障的情况下单位时间内通过的网络的数据数量。单位为Byte/s。用于衡量系统对于网络设备或链路传输能力的需求。 当网络吞吐量指标接近网络设备或链路最大传输能力时，则需要考虑升级网络设备。	Network Throughput	网络吞吐量指标主要有每秒有多少兆流量进出，一般情况下不能超过设备或链路最大传输能力的70%。

3）中间件指标：常用的中间件例如Tomcat、Weblogic等指标主要包括JVM, ThreadPool, JDBC。

指标	二级指标	解释	单位
GC	GC频率	java虚拟机垃圾部分回收频率	每秒多少次
	Full GC频率	java虚拟机垃圾完全回收频率	每小时多少次
	Full GC平均时长	用于垃圾完全回收的平均时长	秒
	Full GC最大时长	用于垃圾完全回收的最大时长	秒
ThreadPool	Active Thread Count	活动的线程数	个
	Pending User Request	处于排队的用户请求个数	个
JDBC	JDBC Active Connection	JDBC活动连接数	个

标准

当前正在运行的线程数不能超过设定的最大值。一般情况下系统性能较好的情况下，线程数最小值设置50和最大值设置200比较合适。

当前运行的JDBC连接数不能超过设定的最大值。一般情况下系统性能较好的情况下，JDBC最小值设置50和最大值设置200比较合适。

GC频率不能频繁，特别是FULL GC更不能频繁，一般情况下系统性能较好的情况下，JVM最小堆大小和最大。

 

4）数据库指标：SQL、吞吐量、命中率、锁。

指标	二级指标	解释	单位
SQL	耗时	执行SQL耗时	微秒
吞吐量	QPS	每秒查询次数	个
	TPS	每秒事务次数	个
命中率	Key Buffer命中率	索引缓冲区命中率	百分之
	InnoDB Buffer命中率	InnoDB缓冲区命中率	百分之
	Query Cache命中率	查询缓存命中率	百分之
	Table Cache命中率	表缓存命中率	百分之
	Thread Cache命中率	线程缓存命中率	百分之

标准

SQL耗时越小越好，一般情况下微秒级别。

命中率越高越好，一般情况下不能低于95%。

锁等待次数越低越好，等待时间越短越好。

 

5）前端指标：页面加载时间、页面数量、网络时间（DNS，连接时间、传输时间等）。

指标	二级指标	解释	单位
页面展示	首次显示时间	在浏览器地址栏输入URL按回车到用户看到网页的第一个视觉标志为止	毫秒
	OnLoad事件时间	浏览器触发onLoad事件的时间，当原始文档和所有引用的内容完全下载后才会触发这个事件	毫秒
	完全载入的时间	所有onLoad JavaScript 处理程序执行完毕，所有动态的或延迟加载的内容都通过这些处理程序触发的时间	毫秒
页面数量	页面大小	整个页面大小	KB
	请求数量	从网站下载资源时所有网络请求的总数，尽量少	次
网络所花时间	DNS时间	DNS查找时间	毫秒
	连接时间	浏览器与Web服务器建立TCP/IP连接的时间	毫秒
	服务器时间	服务器处理时间	毫秒
	传输时间	内容传输所用时间	毫秒
	等待时间	等待某个资源释放的时间	毫秒

标准

页面要尽可能小及压缩。

页面展示和花费时间越短越好。

 

6）稳定性指标

最短稳定时间：系统按照最大容量的80%或标准压力（系统的预期日常压力）情况下运行，能够稳定运行的最短时间。 

一般来说，对于正常工作日（8小时）运行的系统，至少应该能保证系统稳定运行８小时以上。对于7*24运行的系统，至少应该能够保证系统稳定运行24小时以上。

标准

TPS曲线稳定，没有大幅度的波动。

各项资源指标没有泄露或异常情况。

 

7）批量处理指标：指批量处理程序单位时间内处理的数据数量。一般用每秒处理的数据量来衡量。

处理效率是估算批量处理时间窗口最重要的计算指标。

关于批量处理时间窗口，不同系统的批量处理时间窗口在起止时间上可以部分重叠。另外，同一系统内部，也可能存在多个批量处理过程同时进行，其时间窗口相互叠加。

标准

在数据量很大的情况下，批处理时间窗口时间越短越好。

不能影响实时交易系统性能。

 

8）可扩展性指标：指应用软件或操作系统以群集方式部署，增加的硬件资源与增加的处理能力之间的关系。

计算公式为：（增加性能/原始性能）/（增加资源/原始资源）*100%。

扩展能力应通过多轮测试获得扩展指标的变化趋势。

标准

理想的扩展能力是资源增加几倍，性能就提升几倍。

扩展能力至少在70%以上。

 

9）可靠性指标：双机热备、集群、备份和恢复。

指标	测试内容
双机热备	节点切换是否成功及其消耗时间 双机切换是否有业务中断 节点回切是否成功及其耗时 双机回切是否有业务中断 节点回切过程中的数据丢失量
集群	集群中某个节点出现故障时，系统是否有业务中断情况出现 在集群中新增一个节点时，是否需要重启系统 当故障节点恢复后，加入集群，是否需要重启系统 当故障节点恢复后，加入集群，系统是否有业务中断情况出现 节点切换需要多长时间
备份和恢复	备份是否成功及其消耗时间 备份是否使用脚本自动化完成 恢复是否成功及其消耗时间 恢复是否使用脚本自动化完成

 

2. 具体性能的分析流程？

首先看关键指标是否满足需求，如果不满足，需要确定是哪个地方有问题，一般情况下，服务器端问题可能性比较大，也有可能是客户端问题（这种可能性非常小）。

如果是服务器端的问题，需要定位的问题有硬件相关指标，例如CPU，Memory，Disk I/O，Network I/O，如果是某个硬件指标有问题，需要深入的进行分析。如果中间件相关指标没问题，需要查看数据库相关指标，例如：慢查SQL，命中率，锁，参数设置。

如果以上指标都正常，应用程序的算法、缓冲、缓存、同步或异步可能有问题，需要具体深入的分析。

 

3. 如果让你去优化前端页面，你的优化流程是？

遇到问题，第一步是确定问题，先要确定是前端的问题还是后端的问题。

如果是前端的问题，那就要确定在哪些地方出了问题，按照前端的各种检测方法来检查。

如果是后端的问题，就从系统、中间件、数据库、网络等方面入手。

如何确定问题呢？

比如用Firefox的firebug调试，看一次请求在各部分分别花了多少时间，哪些请求耗时最长。

如果请求的是静态资源，时间很长，就需要考虑部署CDN啥的；

如果请求的不是静态资源而是服务器数据，时间长速度慢，那就分两种情况进行考虑：第一是后端的问题，第二是前端渲染问题。

如果返回数据很快，但界面数据没出来，就要考虑是前端js程序问题还是图片等资源太大的问题等等。