WEB性能测试与性能调优总结.docx
- 文档编号:9133561
- 上传时间:2023-05-17
- 格式:DOCX
- 页数:22
- 大小:883.79KB
WEB性能测试与性能调优总结.docx
《WEB性能测试与性能调优总结.docx》由会员分享,可在线阅读,更多相关《WEB性能测试与性能调优总结.docx(22页珍藏版)》请在冰点文库上搜索。
WEB性能测试与性能调优总结
前段时间,我们测试团队对新开发的一个数据分析系统进行性能测试与优化工作,期间遇到不少问题,并分析解决问题。
系统从开始的50用户并发都不满足,优化到最终可以支持500以上并发,性能提升至少10倍以上,感觉很有成就感。
在此,把整个经历过程给大家分享一下,文档是对自己这次性能测试进行一次总结。
经过一个多月的性能测试,收获还是很大的,当然,由于自己经验方面不足,定位时间花费比较长,效率有些低。
因此,写了这篇总结文档,分享下,大家一起进步,也希望对更多的测试人员在性能测试上有所帮助。
一、准备:
局域网搭建测试环境,系统主要模块,sso登陆、数据报表页面查看、地图展示指标数据、大数据分析与结果报表展示。
系统主要是J2EE、后台数据库使用Oracle与hadoop。
目标是测试该系统能否支持500用户同时并发,每个页面或局部刷新响应时间在2秒左右,且长时间运行稳定,也是对系统性能的一次摸底,找出性能瓶颈并优化
二、背景
使用浏览器代理方式,输入首页地址http:
//xxxx
由于我们有SSO登陆,因此跳到登陆页面,输入用户名与密码。
然后进入首页,首页有地图,有报表,类似下图:
三、生成脚本
通过“录制快照”来查看页面HTTP请求,了解我们系统的页面结构,页面时间,即正常浏览器点击到页面显示的时间,每个HTTP的时间与内容长度。
这点也是挺重要的,开始对工具不熟,录制后调通脚本就直接测试,结果发现测试结果有成功有失败,测试结果报告提示脚本时间比录制大,但不知道怎么分析;另外测试发现有些请求时间很大,已经超过10几秒。
然后,测试过程中多次请教了工具的支持人员后,对工具有所了解,也是一些性能测试经验知识。
TPS(TransactionPerSecond)即事务,事务是很重要的。
我们测试的其中一个脚本录制的页面有2个页面,一个ajax局部刷新请求,性能测试要从用户的角度来看,即每个页面完成需要在用户可以忍受的时间内,网上说一般是2秒内认为正常,5秒内有点慢但还可以接受;ajax局部刷新也要在合理的时间。
因此,在支持人员的指导下,为脚本配置了3个事务,2个页面分别事务,一个叫login、一个叫main,然后也对ajax请求配置事务report;这样通过工具的统计信息,就可以单独分析login、main与report3个事务的成功与失败,事务响应时间是否合理,在合理范围内则表示测试通过,如果响应时间大则需要考虑是否合理。
1、录制快照
配置了3个事务后,通过录制快照来分析事务的情况
可以看到每个事务包括了那些请求,该事务录制时花了多长时间,这个时间是测试结果报告里的录制参照值,测试结果报告的事务时间跟这个值对比就知道是否时间合理。
同时,可以看到脚本包括多少个HTTP请求,后台请求有多少个、图片有多少个,主要时间花费在哪里;每个事务包括多少个HTTP请求,多少个服务器,哪个服务器占用时间比较大。
后面测试时,发现很多问题,也是通过录制快照来分析页面结构,发现请求太多、有些请求没有进行缓存(快照的重复有96个)
、图片与JS请求太多,后面进行了合并减少了http请求,也提高了成功率和事务时间。
另外,通过快照里的“并发时间图”来查看每个事务浏览器是怎么并发的,是串行一个一个发送HTTP请求,还是并行多个发送HTTP请求。
这个也非常重要,因为,开始测试时,没有选择模拟浏览器并发,测试出来的事务时间非常大,有的达到几十秒,比正常浏览器点击页面时间2,3秒时间大很多。
后来咨询了工具的支持人员,才知道有并发跟串行的说法,下图可以看到,浏览器基本是并发执行请求的,后来网上了解了浏览器并发原理,还有通过浏览器的F12的网络分析也发现确实是同时并发HTTP请求的。
听工具支持人员说,好像现在其他测试工具是不支持一个虚拟用户并发HTTP请求的,以前用loadrunner也没去研究,不过好像确实测试的时间总比正常浏览器访问要大。
这个后面再确认,如果真是这样的话,那确实工具这点挺好的;因为每个用户的并发与浏览器一样,对服务器的压力就基本类似,测试的结果响应时间也真实反映每个用户的情况,如果是串行的话,时间大了也不知道怎么分析。
2、脚本调试
脚本录制后,开始测试前需要对脚本进行调试。
回放、关联、参数化、验证脚本;通过工具提供的帮助知道文档和支持人员的交流,脚本顺利调试通过,也通过后台数据库和工具的验证页面功能查看,脚本通过。
OK,下面开始性能测试和结果分析、调优了。
四、第一阶段测试
开始没配置login、main与report3个事务,也没配置模拟浏览器并发,调试通过后就直接跑,可能是自己对性能测试经验不足,不知道配置事务这么重要。
同时并发50个用户,看下怎样结果
测试多次的结果,有时都成功,有时存在2,3个用户失败,但脚本执行时间居然80%以上达到将近50秒,2个页面一个ajax局部刷新,正常使用浏览器时,也才几秒,应该不可能达到这么大啊。
测试时,自己使用浏览器访问页面,有时地图加载失败,有时成功,页面出来也比平常慢。
懵了,怎么定位呢,经验严重不足。
先从工具提示与统计来分析,再加上请教了工具的支持人员,也学到了一些分析方法。
工具汇总报告如下:
查看“用户详情”的“用户与事务统计”如下:
可以发现80%用户总时间达到47秒左右,但录制时使用浏览器整个时间才7820毫秒,即录制值,相差非常大。
查看“脚本请求统计”分析HTTP请求,如下图:
查看每个HTTP请求的统计信息,最大响应时间、90%、80%时间。
这里支持点击列排序即可以找出时间最大的HTTP请求有哪些。
点击“详细分析”
查看更细分的统计,可以按域名、HTTP类型等分析
其中,访问google有两个请求时间比较长,另外,界面下面给出域名占总时间比例还是比较大,因此可以确认访问google是一个瓶颈点,工具用到google地图。
在“脚本请求统计”界面的滚动条拉下来可以看到,有哪些请求失败,失败原因是什么,下面是50用户都成功时的统计,显示TCP建立时间超过3秒,表示这些请求响应时间太大,应该是TCP建立时间长导致。
如果这里有其他失败,也可以看到统计,很方便分析。
根据根据分析,初步确认google的请求时间比较大,那为什么会大呢,需要定位找原因并解决,由于自己在性能测试经验上欠缺,问了工具的客服人员,说可能是网络原因,汇总报告里也提示建立TCP时间长可能是网络原因。
OK,咨询我们的网络人员,网络人员给了个Ping如下:
正在Ping[64.18.0.10]具有32字节的数据:
来自64.18.0.10的回复:
字节=32时间=542ms
来自64.18.0.10的回复:
字节=32时间=420ms
来自64.18.0.10的回复:
字节=32时间=511ms
来自64.18.0.10的回复:
字节=32时间=480ms
发现测试环境到google服务器的网络时延比较大,达到500多毫米。
另外,分析访问SSO服务器的HTTP也时间也比其他HTTP长,但比google时间要小一些。
网络人员给出的解释是,因为公司网络到SSO服务器和到google服务器的带宽比较小,而且是办公网络,当前是办公时间,大家都在使用网络。
SSO服务器网络原因解决办法比较容易,让网络人员对测试环境的网络做一些配置;而google响应慢与开发交流,先不理,后面可能会专门开发个缓存代理,不用每次都去google访问。
所以,测试脚本中把google的HTTP请求删除掉,目前测试我们自己服务器,先不管google。
五、第二阶段测试
为脚本配置了3个事务,目的是从事务的响应时间来分析页面或局部刷新的时间是否合理;2个页面分别事务,一个叫login、一个叫main,然后也对ajax请求配置事务report;
前面通过修改网络和删除google地图相关HTTP请求,响应时间提升了10多秒。
但还是40秒左右,离我们目标每个页面2-5秒范围相差很大。
测试过程在同事电脑上使用浏览器访问页面,也还是很慢,证明系统可能有瓶颈。
怎么优化呢,第二阶段与第三阶段性能测试耗时最长的优化就是这阶段,也是最具有挑战性的阶段。
发现了很多问题,通过优化,性能提升很大。
网上查资料、看论坛,大概意思就可能是网络原因、数据库原因、CPU、内存的;OK,在测试时添加服务器监控,在工具controller界面添加服务器、数据库内存与CPU监控,配置添加monitor监控器
运行结果发现tomcat的CPU与内存很低,但数据库CPU在查询时有点彪升,因为页面涉及到地图数据、报表数据都需要访问数据库。
通过工具详情分析里的HTTP后台动态类型分析,部分HTTP请求时间比较大
与开发交流,开发团队给出了解决方案,增加redis缓存,把一些常用不改变的数据,如地图边界、常用报表在tomcat启动时就加载到缓存,另外,把数据库查询结果保存到缓存,如果是一样的查询语句,则直接从缓存读取,减少到数据库查询,提高效率,终于把后台数据库查询的HTTP请求时间降下来。
六、第三阶段测试
1、脚本修改为模拟浏览器并发
上面通过redis缓存解决了后台数据库并发性能差的问题,响应时间得到大幅下降,总的响应从40多秒时间降到20秒左右,3个事务响应时间分别在6,9,5左右。
多次测试仍然还是20秒,但测试过程使用浏览器访问页面都正常,页面出来时间也大概1,2秒时间。
经验不行,不懂怎么办了。
此次测试是摸底系统是否可以支持500用户数并发,即页面访问都成功、而且每个页面或局部刷新响应时间在2-5秒范围内;现在每个HTTP请求,都比较合理,与录制值比较相差不大,但每个事务时间在8秒左右,总时间20秒左右,以为系统无法支持500用户;
咨询工具支持人员,原来脚本没配置“模拟浏览器并发”,然后启用“模拟浏览器并发”终于把时间降下来,降到10秒左右,login事务对应页面、main事务对应页面,局部刷新事务report的响应时间都在3秒左右,正常范围,50个用户通过。
为什么要“模拟浏览器并发”,问了工具的支持人员,原理大概是我们使用浏览器访问页面时是并发的,可以通过浏览器的F12调试工具的网络查看页面的HTTP请求;网上搜索了下,好像一个域名可以同时并发6个请求,那我们系统有多个域名,至少6个并发以上;
如果没有配置“模拟浏览器并发”工具执行脚本时是串行一个一个HTTP执行,那当然比正常浏览器慢。
另外,工具串行500个并发比浏览器500个并发压力不是一个量级,可能相差好几倍。
如252辆车(252个HTTP请求)要到达目的的,一个是一车道(串行)还堵车(阻塞),一个是6车道(并行),时间差别很大,对服务器压力也差别大。
2、逐步提高并发用户
从并发50用户数,慢慢提升到并发100、150、200、250、300、400、500用户数。
当运行到150时,出现脚本执行时间变大,最小有10秒左右,但大部分在15秒,也出现TCP建立时间超过3秒,类似上面开始测试时,google的HTTP请求响应时间大。
但自己在并发测试时使用浏览器访问,页面显示正常,可能比平时稍微慢点点,但也没那么明显,因此感觉是工具问题。
工具报告提示:
查看“脚本请求统计”分析HTTP请求,没有特定HTTP比较慢,而是整体响应时间都大了,有一些小的CSS文件也比较慢,如下图:
也可以看到大文件的“首个接收分片”比较快,但后面的剩余数据接收时间比50用户时要大,如下图
在XX里搜索,还有咨询了支持人员,发现这种现象一般是网络延时,带宽不足或CPU太大问题。
根据工具提示的汇总报告,也表示可能是CPU高、网络拥塞;查看服务器CPU,才8%CPU,那应该是网络问题,但我现在是在局域网里面,网络很好,而且自己使用浏览器访问正常,感觉不可能是网络问题。
后面注意到汇总报告有一个吞吐量告警:
查看了工具所在机器的网卡,是100Mbit网卡,服务器是1000Mbit网卡,即瓶颈在工具所在电脑的网卡。
50用户总吞吐量为56750KB(约56MB),即每个用户吞吐量大约1.1MB,对服务器每秒的压力是56MB/10秒=5.6MB,换算成比特,就是44Mbit/秒,那么150用户就大约130Mbit,超过网卡极限。
咨询了工具支持人员,他告诉我解决办法有两个,一个是采用多个agent执行器分布式执行,这样可以避免网卡瓶颈;另一个,他看了脚本录制快照后,发现我们脚本HTTP请求太多,重复也太多,给我建议需要优化页面,可以采用缓存,减少HTTP个数、压缩文件、合并文件(图片、CSS、JS)。
因此在网上找找这方面的资料,在网上看了很多文档:
例如
从工具“录制快照”看到,一个脚本里面有96个重复HTTP请求,总共有252请求
重复里面点击URL排序可以看到有些CSS、图片重复多次,如下:
CSS、JS、图片多次请求,而且都返回一样的内容,即一个文件请求了多长,如果使用缓存,则可以减少CSS、图片的下载。
另外,按字节大小进行排序,可以看到一个地图相关的HTTP请求内容长度达到近340KB,内容格式为json,而且没有压缩;js文件达到455KB,也没压缩。
从测试结果看到,该请求响应时间也比较大;
把当前问题告诉开发负责人,开发负责人也意识到这些会影响性能,整改页面结构与代码。
3、整改页面结构
经过整改,为tomcat增加了缓存、压缩JS、后台代码压缩json、合并很多小文件。
重新录制页面脚本,发现HTTP请求总数从252减少到104个,减少了近150个HTTP请求;JS与json压缩率也非常高,340KB的json数据,经过压缩后,只占约8K,压缩比惊人。
再次测试,50个用户由之前的10秒左右,降到近5秒多,3个事务的时间也都在1-2秒左右;当并发150个用户脚本执行时间也在6秒左右;性能提升还是比较大的。
为防止测试工具的执行器Agent瓶颈,后面测试使用了两个执行代理器local与linux分布式测试。
再次递增用户200个,也是近6秒多,3个事务的时间也都在2秒左右,还算正常;递增到500个时,脚本响应时间明显加大,有部分用户时间已经达到12秒,更有达到15秒以上,也出现用户失败,出现部分JS或图片访问失败,失败日志如下:
日志大概意思是服务器在发送HTTP请求后的6秒左右关闭了TCP连接,所以没收到HTTP请求的响应,导致用户失败。
测试时使用浏览器访问,确实页面出来慢了很多,有时也页面出不来,应该是服务器问题。
工具给出的汇总报告有如下告警:
咨询支持人员,从经验看应该是CPU太大或者线程池、连接池不够,导致HTTP请求无法处理,tomcat服务器主动关闭TCP。
看了服务器的CPU,服务器CPU有8核,CPU只占20%左右,应该不是CPU原因;但查看数据库所在的CPU比较高。
奇怪呢,数据库高应该只影响访问数据库的HTTP请求才对,怎么连图片或JS也失败呢。
最后,我们开发团队一位牛人,通过java的dump日志,发现是线程阻塞了,数据库访问太大,导致线程都阻塞在等数据库的响应,无法再处理其他HTTP请求,包括图片与JS。
解决办法,提高数据库连接池个数,提高tomcat线程池大小,同时配置阻塞为非阻塞NIO:
maxThreads="500"minSpareThreads="100"/> connectionTimeout="20000" redirectPort="8443"/> 4、调整线程池、数据库连接池 配置完后再次500个并发用户多次测试,总的脚本响应时间与3个事务响应时间都在正常范围,终于支持500并发用户数了。 当然,由于我们脚本录制时请求都没包括缓存头域,正常用户访问时,部分图片或JS、CSS请求浏览器已经缓存了,所以正常的500用户并发对服务器的压力应该比脚步500并发要小些,因为部分图片或JS、CSS不需要再请求。 到此,已经可以支持500用户了,后面还需要进行稳定性长时间测试。 七、第四阶段稳定性测试 一个用户完成脚步大概7秒时间,因此每秒启动70个用户,保证后面近500用户同时在线 长时间测试稳定性也是很重要,此次测试期间发生过redis缓存挂了、tomcat内存溢出、 1、redis缓存挂了 长时间运行近50分钟后,发现后面的用户都失败了。 从测试统计结果与日志提示发现失败原因是服务器返回500响应,失败的HTTP请求为访问数据库的HTTP请求。 此时,使用浏览器访问系统,页面也出不来,无法正常显示。 后来,查询服务器发现redis进程不存在,多次测试都这样,开发定位说是内存问题,同时也暴露了redis单点问题,架构上需要考虑主备。 2、几小时后失败用户数递增 Redis内存问题解决后,在长时间运行4个多小时,发现失败用户数占约5% 点击“用户详情”分析结果如下: 失败类型基本是跟TCP连接相关,也存在接收超时 查看“失败用户图”,失败用户基本在4小时(14000秒)后 失败类型为“TCP建立失败”、“服务器关闭TCP导致无响应”也基本是发生在4小时后 那么运行到4小时后发生什么情况导致失败用户数递增呢 查看了在线数,发现0秒到3小时50分时比较平稳,大概在740个用户,但到了4小时的时候,在线用户数飙升到3000多,对系统造成的压力远大于正常,所以脚本失败与响应时间都增大。 放大图表,可以看到3小时之后基本都在3000多在线用户数 运行多次长时间运行,必会出现这种情况,后面一位开发牛人分析发现是阻塞与jvmfullgc垃圾回收频繁导致。 检查了数据库SQL语句性能,发现有些没添加主键,日期格式是字符串格式,导致效率差;部分SQL语句通过SQL执行计划分析发现筛选条件不合理。 从而导致脚本执行时间长,然后又由于新用户一直在递增,所以就出现老用户还没结束新用户又增加导致在线用户数达到3000多。 解决思路,系统部署环境由只有一个tomcat改为Ngnix+tomcat,把静态的CSS、JS、图片、HTML放到Ngnix,Ngnix启用缓存;把动态的HTTP交互交给tomcat处理,这样减轻了tomcat的压力与TCP连接。 数据库增加主键、修改SQL语句提高查询效率。 3、tomcat也挂了 优化SQL语句和改为Ngnix+tomcat部署后,基本没发生前面的情况,但在运行到2天多时,还出现tomcat也挂掉,查看日志发现时内存溢出了。 我们使用的是linux16G内存,把jvm的内存参数改为-Xms2560–Xmx2560后就没发生过内存溢出的情况。 最后,使用工具运行近93小时,基本都成功了,且脚本时间与录制时的时间基本一样9秒左右;报告显示存在失败,但失败率非常低,约为0%,分析数据发现失败主要是创建TCP失败或接收超时,而且基本发生在HTTP请求是图片与JS的情况,这个一时半会定位不出来,如果用户有缓存,概率更小。 八、心得 最后,总结下,性能测试是挺需要技术含量的,不仅仅是会使用性能工具就能测试,还包括很多方面的知识与经验,此次测试发现自己经验真的很不足。 下面根据自己体会列几点: 1、性能测试前需要对系统有一些了解,流程、架构等,这样才大体知道出问题怎么定界,是哪个模块的问题 2、性能测试工具只是一种工具,性能测试不只是会使用性能工具,还包括很多方面,要学会怎么使用工具的结果进行分析。 当然,能熟练使用性能测试工具也很重要,测试才比较高效率;另外,选择测试的性能工具也很重要,需要具备结果分析功能,提供分析手段,不然可能不知道怎么分析,效率也低。 这次测试使用的性能测试工具比较给力,功能全、结果数据也很全,且比较傻瓜化。 3、了解性能指标,其实感觉就是成功失败、响应时间、事务成功失败、事务时间这些指标,但怎么配置事务,事务响应时间多少合理,也是需要了解;事务配置以用户感知来配置是最好的,因为用户看到的是页面或点击是否成功、页面或点击响应时间是否正常;所以,一般一个页面配置一个事务,一次点击(局部刷新或跳转页面)配置一个事务。 另外,测试过程需要关注CPU、IO、吞吐量、网络带宽、内存等指标 4、如果能对页面与后台的HTTP交互流程有了解更好,这样知道哪些HTTP做哪些动作,这样哪些HTTP请求失败或响应慢就可以对照后台是怎么处理的,是计算复杂、还是需要请求数据库、缓存;此次测试,发现有几个HTTP请求慢或失败收到500响应,与开发交流确认是数据库和redis缓存,后面通过调优数据库和调大redis内存解决了问题。 5、一些网页前端性能调优方法,如合并请求(多个小图片合并、CSS合并)、压缩(数据太大压缩包括JS、后台数据)提高效率、启用缓存减少HTTP请求。 这些也很重要,在此次测试开始因为我们页面请求太多、没缓存导致事务响应时间大,这个可以通过性能工具的“录制快照”了解。 6、启用“模拟浏览器并发”与没启用相差很大,因为浏览器是并发的,那模拟的虚拟用户应该也需要并发,这样测试支持的用户数才匹配。 7、经验很重要,自己以前也用过loadrunner做过性能测试,但不深,只知道一些基本操作,录制脚本、测试;此次测试出现问题开始也不知道怎么分析,如果有性能经验丰富的人指导,效率就高很多,也能学到东西。 这里,感谢下kylinPET工具的支持人员,教了不少东西。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- WEB 性能 测试 总结