性能测试四十五:性能测试策略
Posted malinalian
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了性能测试四十五:性能测试策略相关的知识,希望对你有一定的参考价值。
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程序问题还是图片等资源太大的问题等等。
以上是关于性能测试四十五:性能测试策略的主要内容,如果未能解决你的问题,请参考以下文章