B2C业务后台压力测试报告.docx
《B2C业务后台压力测试报告.docx》由会员分享,可在线阅读,更多相关《B2C业务后台压力测试报告.docx(13页珍藏版)》请在冰豆网上搜索。
B2C业务后台压力测试报告
B2C业务后台测试报告
1、测试内容:
本次压力测试是仿B2C业务后台的实际应用的软硬件环境及用户使用过程的系统负荷,长时间运行测试软件来测试被测服务器的可靠性,同时记录LoadRunner执行脚本的相关内容,分析出系统各个瓶颈。
1.1测试项:
1.1.1登录(计划模拟20、50、100、200并发)
1.1.2登录后在预订中心的订单管理里面查询今天的订单(计划模拟20、50、100、200并发)
1.1.3登录后在预订中心的预订机票里面查询航班信息(计划模拟20、50、100、200并发)
1.1.4登录后在出票中心的报表里面查询最近一个月的报表(计划模拟20、50、100、200并发)
1.1.5登录后在酒店管理的酒店订单查询里面查询最近一个月的酒店订单(计划模拟20、50、100、200并发)
1.2测试工具:
LoadRunner8.1,IE8浏览器
1.3测试系统要求:
内存最好在512M以上,安装LoadRunner的磁盘空间至少剩余500M。
操作系统最好是Windows2000。
1.4测试环境:
计算机品牌:
联想笔记本
操作系统:
微软WindowsXP专业版Build2600(ServicePack3)CPU:
双核
内存:
2GBytes
磁盘:
WDCWD3200BEVT-22ZCT0
本机空载时Memory和CPU情况:
1.5使用LoadRunner进行压力测试的步骤:
1.5.1录制脚本:
打开登录界面:
http:
//172.16.2.87:
8081/bko/;输入用户名:
test,密码:
【保密】,分机号:
【为空】;点击“进入”按钮进行相关操作,等页面录制完毕才能关闭浏览器,再停止录制,然后回放脚本检查,最后确定回放的脚本要正确。
1.5.2执行脚本:
打开相关的脚本,设置好脚本运行的参数,执行脚本并且记录响应时间、最大/最小并发数、失败的次数、正常连续运行的最长/最短时间,并发数与失败的关系。
1.5.3对脚本录制过程中进行分析:
系统能够承受多大的压力,虚拟用户几个同时进行操作作为标准,记录有用数据并且进行分析。
2、测试结果【只做了登录的压力测试,下面其他的需要把问题解决后才能进行测试】:
2.1登录(计划模拟20、50、100、200并发)【每秒加载4,达到并发数持续5-10分钟,每秒停止4个】
2.1.1LoadRunner记录的相关参数如下:
Vusers数:
400
最大并发用户数:
400
TotalTrans/Sec(Passed)业务操作响应时间是:
HisperSecond每秒点击数:
Throughput吞吐量:
PagesDownloadedperSecond下载组件大小:
TransResponseTime
RunningVusers
HTTPResponsesperSecond
ConnectionsPerSecond
VuserswithErrors
问题1:
2.1.2服务器相关参数如下:
Memory【内存】、CPU:
在达到400并发持续运行6、7分钟CPU就占满了,如下图所示:
这证明在登录并发量至高达到400个并发。
Tomcat问题:
在连接过程中有些用户未能连接,如下图:
这证明数据库需要优化。
2.2登录后在预订中心的订单管理里面查询今天的订单(计划模拟20、50、100、200并发)【每秒加载4,达到并发数持续5-10分钟,每秒停止4个】
LoadRunner记录的相关参数如下:
Vusers数:
最大并发用户数:
TotalTrans/Sec(Passed)业务操作响应时间是:
HisperSecond每秒点击数:
Throughput吞吐量:
PagesDownloadedperSecond下载组件大小:
服务器相关参数如下:
Memory【内存】:
CPU:
2.3登录后在预订中心的预订机票里面查询航班信息(计划模拟20、50、100、200并发)【每秒加载4,达到并发数持续5-10分钟,每秒停止4个】
LoadRunner记录的相关参数如下:
Vusers数:
最大并发用户数:
TotalTrans/Sec(Passed)业务操作响应时间是:
HisperSecond每秒点击数:
Throughput吞吐量:
PagesDownloadedperSecond下载组件大小:
服务器相关参数如下:
Memory【内存】:
CPU:
2.4登录后在出票中心的报表里面查询最近一个月的报表(计划模拟20、50、100、200并发)【每秒加载4,达到并发数持续5-10分钟,每秒停止4个】
LoadRunner记录的相关参数如下:
Vusers数:
最大并发用户数:
TotalTrans/Sec(Passed)业务操作响应时间是:
HisperSecond每秒点击数:
Throughput吞吐量:
PagesDownloadedperSecond下载组件大小:
服务器相关参数如下:
Memory【内存】:
CPU:
2.5登录后在酒店管理的酒店订单查询里面查询最近一个月的酒店订单(计划模拟20、50、100、200并发)【每秒加载4,达到并发数持续5-10分钟,每秒停止4个】
LoadRunner记录的相关参数如下:
Vusers数:
最大并发用户数:
TotalTrans/Sec(Passed)业务操作响应时间是:
HisperSecond每秒点击数:
Throughput吞吐量:
PagesDownloadedperSecond下载组件大小:
服务器相关参数如下:
Memory【内存】:
CPU:
3、具体结果以及如何得到:
3.1分析原则:
1.具体问题具体分析(这是由于不同的应用系统,不同的测试目的,不同的性能关注点)
2.查找瓶颈时按以下顺序,由易到难。
服务器硬件瓶颈
网络瓶颈(对局域网,可以不考虑)
服务器操作系统瓶颈(参数配置)
中间件瓶颈(参数配置,数据库,web服务器等)
应用瓶颈(SQL语句、数据库设计、业务逻辑、算法等)
3.2分析的信息来源:
1根据场景运行过程中的错误提示信息
2根据测试结果收集到的监控指标数据
3.2.1错误提示分析:
分析实例:
3.2.1.1实例1
Error:
Failedtoconnecttoserver“172.16.2.87″:
[10060]Connection
Error:
timedoutError:
Server“172.16.2.87″hasshutdowntheconnectionprematurely
分析:
A、应用服务死掉。
(小用户时:
程序上的问题。
程序上处理数据库的问题,实际测试中多半是服务器链接的配置问题)
B、应用服务没有死(应用服务参数设置问题)
对应的Apache和tomcat的最大链接数需要修改,如果连接时收到connectionrefused消息,说明应提高相应的服务器最大连接的设置,增加幅度要根据实际情况和服务器硬件的情况来定,建议每次增加25%!
C、数据库的连接,数据库启动的最大连接数(跟硬件的内存有关)。
D、我们的应用程序spring控制的最大链接数太低
3.2.1.2实例2
Error:
Pagedownloadtimeout(120seconds)hasexpired
分析:
A、应用服务参数设置太大导致服务器的瓶颈
B、页面中图片太多
C、在程序处理表的时候检查字段太大多
D、实际测试时有些资源需要请求外网,而我们的测试环境是局域网环境
3.2.1.3实例3
Error“http:
//172.16.2.87:
8081/bko/......”
分析:
A、脚本设计错误,造成页面异常。
服务器有响应!
B、并发数过大,造成服务器响应延迟。
3.2.1.4实例4
Errorpage“text=xxxxx”
分析:
A、脚本设计问题,例如,前一脚本修改了某些内容,造成后面的脚本访问异常。
B、不确定因素,有时候回放正常的脚本,一放到场景中就出现这样的错误。
只能反复修改脚本!
3.2.2监控指标数据分析
3.2.2.1Vusers数
Loadrunner系统设置的虚拟用户数目。
Vuser去实际调用事先制作的脚本文件中的应用。
每个Vuser产生响应的操作,所有的操作对服务器形成并发。
颜色比例度量图最小值图平均值图最大值图中间值图SD
1Run0.021.25444121.276
在实际测试中,Vusers可以根据实际情况的需要,在测试过程中增加或者减少。
3.2.2.2最大并发用户数:
颜色比例度量最小值平均值最大值SD
100ApacheCPU使用情况(Apache):
172.17.7.2100.7770.8520.930.043
0.01已发送KB/秒(Apache):
172.17.7.21061430.3712689.333327.924
0.1点击次数/秒(Apache):
172.17.7.2100.333114.352533.66740.201
应用系统在当前环境下能承受的最大并发用户数。
在方案运行中,如果出现了大批用户的业务操作失败,或出现了服务器shutdown的情况,则说明在当前环境下,系统承受不了当前并发用户的负载压力,那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
从上图可以看出:
在测试运行到4个小时左右的时候,apache的点击数/秒开始迅速增加!
3.2.2.3业务操作响应时间:
使用“事务性能摘要”图,可以确定在方案执行期间响应时间过长的事务。
颜色比例度量
1最小值
1平均值
1最大值
分析事务的响应情况,要每次详细分析,目前还只能观察到响应时间过长的事务!
3.2.2.4每秒点击数
负载测试期间每秒内Vuser在Web服务器上点击的次数。
可根据点击次数来估算Vuser生成的负载数。
颜色比例度量图最小值平均值图最大值图中间值图SD
1点击次数69.908105.736130.244103.66612.186
从图中不难看出,在4小时的时候,点技数明显增高。
和apache的每秒点击数增大的时间相吻合!
3.2.2.5吞吐量
负载测试期间Web服务器上的吞吐量(字节)。
吞吐量表示在任何指定秒内Vuser从服务器接收到的数据量。
此图可估计Vuser生成的负载量(服务器吞吐量)。
颜色比例度量图最小值平均值图最大值图中间值图SD
1Throughput1257502.7951375591.3721525865.0471372743.69149130.473
同样,从图中可以看出,在4个小时的时候,web服务器的吞吐量开始增高。
在图中还可以看到吞吐量的走势图,从开始到进行到4个小时反弹之前呈降低的趋势,这是因为系统在初期调用的资源都是直接来之服务器,运行一段时间后系统的部分资源来自缓存。
3.2.2.6下载组件大小
每个页面的组件大小,且包括组件的标头的大小!
页面组件大小的分析表格比较复杂,实际分析中可以通过loadrunner的报告分析工具来分析。
页面组件大小分析主要是找到页面中比较庞大的组件,如果其影响到了页面的下载速度,则要想办法将其改小!
3.2.2.7Apache资源
显示APACHEweb服务器上的资源摘要。
前面已经提到过以并发点击数为主。
颜色比例度量最小值平均值最大值SD
100ApacheCPU使用情况(Apache):
172.17.7.2100.7770.8520.930.043
0.01已发送KB/秒(Apache):
172.17.7.21061430.3712689.333327.924
0.1点击次数/秒(Apache):
172.17.7.2100.333114.352533.66740.201
3.2.3服务器资源监控指标(目前通过top监察):
3.2.3.1内存:
Windowsserver2003资源监控中指标内存页交换速率(Pagingrate),如果该值偶尔走高,表明当时有线程竞争内存。
如果持续很高,则内存可能是瓶颈。
也可能是内存访问命中率低。
实际测试中,当并发点击数出现突然剧增前后,内存的PR值则居高25不下。
说明目前测试的系统中内存存在瓶颈!
内存资源成为系统性能的瓶颈的征兆:
很高的换页率(highpageoutrate);
进程进入不活动状态;
交换区所有磁盘的活动次数可高;
可高的全局系统CPU利用率;
内存不够出错(outofmemoryerrors)
3.2.3.2处理器:
Windowsserver2003资源监控中指标CPU占用率持续超过80%(对该值的要求,根据具体应用和机器配置而要求不同,有资料表明95%),表明瓶颈是CPU。
实际测试中,当并发点技数出现突然增加前后,cpu的占用率持续保持在86%以上!
说明,目前系统用应用的cpu也是测试的瓶颈!
CPU资源成为系统性能的瓶颈的征兆:
很慢的响应时间(slowresponsetime)
CPU空闲时间为零(zeropercentidleCPU)
过高的用户占用CPU时间(highpercentuserCPU)
过高的系统占用CPU时间(highpercentsystemCPU)
长时间的有很长的运行进程队列(largerunqueuesizesustainedovertime)
3.2.4数据库服务器:
数据库服务器目前测试观察,当web服务器点击率增大时,观察mysql数据库的最大连接数,仍未超过系统设置的最大连接数。
所以,暂时未发现数据库的瓶颈!
3.2.5分析的结论:
以上报告分析中的数据、图标均来自同一次测试。
是在平时测试中挑出的一次现象比较明显,比较利于观察的作为分析案例。
根据以上分析结果综合分析,当前测试环境下,当应用系统产生最大533.667的并发压力。
平均负载压力114.352。
根据分析,用户在4个小时的时候,并发数迅速增加前后的值在400左右!
分析结果跟实际测试的硬件环境以及测试脚本有一定关系。
同时,测试服务器的硬件配置和实际服务器的配置还有一定的差距!
测试时间:
2010-5-10
测试工程师:
梁英杰