码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2019-01-30 00:19:44      阅读:122      评论:0      收藏:0      [点我收藏+]

标签:返回   应用软件   负载   ESS   异步   就是   工作日   用户   命中   

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小时)运行的系统,至少应该能保证系统稳定运行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程序问题还是图片等资源太大的问题等等。

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

标签:返回   应用软件   负载   ESS   异步   就是   工作日   用户   命中   

原文地址:https://www.cnblogs.com/zhongyehai/p/10336334.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有 京ICP备13008772号-2
迷上了代码!