CMS系统性能测试报告.docx
- 文档编号:7694705
- 上传时间:2023-01-25
- 格式:DOCX
- 页数:26
- 大小:242.84KB
CMS系统性能测试报告.docx
《CMS系统性能测试报告.docx》由会员分享,可在线阅读,更多相关《CMS系统性能测试报告.docx(26页珍藏版)》请在冰豆网上搜索。
CMS系统性能测试报告
金融界CMS系统
性能测试报告
文档编号:
JRJ-LoadTestReport-070808
作者:
齐国杰
编写日期:
2007-8-8
Email:
Guojie.qi@
版本记录:
版本号
更新内容
更新人
更新时间
1.0
新建
齐国杰
2007-8-8
一、测试结果概述
1、测试简要记录
测试简要记录:
功能点
虚拟人数
是否并发
持续时间
事务总数
执行失败数
平均响应时间
平均每秒事务数
CPU使用率
信息添加
500
否
5分钟
4767
91
15.5秒
11.337个
57.60%
信息添加
100
否
5分钟
3413
0
7.5秒
10.767个
53.20%
信息添加
100
是
3分钟
1621
0
7.0秒
6.957个
49.28%
碎片添加
500
否
5分钟
5173
921
15.8秒
13.123个
49.40%
碎片添加
100
否
5分钟
2961
0
0.094秒
15.107个
23.73%
碎片添加
100
是
3分钟
1900
0
0.096秒
10.106个
17.32%
专题修改
200
否
5分钟
3380
0
18.936秒
9.988个
14.61%
信息签发
300
否
3分钟
5763
64
9.741秒
24.046个
7.10%
信息签发
100
是
3分钟
5704
114
3.23秒
30.054个
6.88%
2、信息添加
2.1、压力测试一
测试需求:
预计初期最大用户为50个,使用时间为全天候24小时
测试设计:
500个用户在5分钟内迭代添加信息
结果分析:
事务平均响应时间较高,平均15秒;
服务器CPU使用率超过50%;
平均事务数为11个/秒;
测试结论:
在这个方案的压力下,系统表现非常不好,效率下降;CPU占用严重,建议优化
2.2、压力测试二
测试需求:
预计初期最大用户为50个,使用时间为全天候24小时
测试设计:
100个用户在5分钟内迭代添加信息
结果分析:
事务平均响应时间稍高,平均7.5秒;
服务器CPU使用率超过50%;
平均事务数为10.5个/秒;
测试结论:
CPU占用严重,对比推测信息添加操作对服务器CPU压力很大,建议优化
2.3、并发测试
测试需求:
目前设计最大支持并发为100个;应该支持300-500个用户使用
测试设计:
采用集合点,集合100个用户进行迭代3分钟的测试
结果分析:
事务平均响应时间稍高,平均7秒;
服务器CPU平均使用率49%;
平均事务数约为7个/秒;
测试结论:
CPU仍然占用较高,证实了压力测试二的结论
3、碎片添加
3.1、压力测试一
测试需求:
预计初期最大用户为50个,使用时间为全天候24小时
测试设计:
500个用户在5分钟内迭代添加碎片
结果分析:
事务平均响应时间较高,平均15秒;
服务器CPU平均使用率49%;
平均事务数为13个/秒;
测试结论:
在这个方案的压力下,系统负担较重,建议优化
3.2、压力测试二
测试需求:
预计初期最大用户为50个,使用时间为全天候24小时
测试设计:
100个用户在5分钟内迭代添加碎片
结果分析:
事务平均响应时间非常低
服务器CPU使用率比较正常
平均事务数为15个/秒;
测试结论:
通过
3.3、并发测试
测试需求:
目前设计最大支持并发为100个;应该支持300-500个用户使用
测试设计:
采用集合点,集合100个用户进行迭代3分钟的测试
结果分析:
事务平均响应时间非常低
服务器CPU使用率比较正常
平均事务数为10个/秒;
测试结论:
通过
3、专题修改
测试需求:
专题修改使用人数较少,适当进行测试即可
测试设计:
200个用户在5分钟内迭代修改一个专题的某个模块
结果分析:
事务平均响应时间非常高,达到18秒左右
服务器CPU使用率比较正常
平均事务数为10个/秒;
测试结论:
平均响应时间较高,建议优化一下
4、信息签发
4.1、压力测试
测试需求:
预计初期最大用户为50个,使用时间为全天候24小时
测试设计:
300个用户在3分钟内迭代签发,并取得返回值验证签发成功
结果分析:
事务平均响应时间稍高,平均9秒;
服务器CPU平均使用率正常;
平均事务数为24个/秒;
测试结论:
通过
4.2、并发测试
测试需求:
目前设计最大支持并发为100个;应该支持300-500个用户使用
测试设计:
采用集合点,集合100个用户进行迭代3分钟的测试
结果分析:
事务平均响应时间非常低
服务器CPU使用率比较正常
平均事务数为30个/秒;
测试结论:
通过
5、疲劳测试
测试需求:
预计初期最大用户为50个,使用时间为全天候24小时
测试设计:
50个用户同时进行信息添加、碎片添加、专题修改操作,持续24小时
结果分析:
事务平均响应时间很高(添加信息17秒、添加碎片9秒、修改专题31秒)
服务器CPU使用率较高,平均46%
测试结论:
运行10多分钟,系统开始出现错误(例如一些页面开始出现500错误),并且CPU使用率很高;通过对linux的监测发现是因为web服务器的连接数满了造成的,需要优化一下
二、测试环境说明
时间:
2007-8-3到2007-8-7
测试人员:
齐国杰
测试工具:
Loadrunner8.1试用版
测试环境:
硬件环境:
软件环境:
服务器为192.168.1.115,系统为linux;web服务是tomcat
测试机为WindowsXP专业版sp2
网络环境
局域网
三、详细测试结果
1、信息添加
1.1、测试需求
添加信息测试页面:
:
8080/cms/UI/spec/addspec.faces
需求说明:
预计初期最大用户为50个,使用时间为全天候24小时
目前设计最大支持并发为100个;应该支持300-500个用户使用
测试设计:
方案一:
500个用户在5分钟内迭代添加信息
方案二:
100个用户在5分钟内迭代添加信息
方案三:
采用集合点,集合100个用户进行并发,并迭代3分钟
1.2、基本测试数据记录(平均值)
事务响应时间(S)
每秒点击数
每秒HTTP请求响应数
每秒连接数
服务器CPU占有率(%)
方案一
14.524
751.068
751.036
690.713
57.6
方案二
7.469
699.826
699.826
249.681
53.178
方案三
7.012
475.013
475.013
102.88
49.281
1.3、Analysis记录结果
(1)测试结果概述
方案
事务运行总数
事务失败数
事务通过率
事务执行速率
方案一
4767
91
98.09%
11.337个/秒
方案二
3413
0
100%
10.767个/秒
方案三
1621
0
100%
6.957个/秒
(2)虚拟用户运行情况
(根据基本测试数据记录来分析,方案一运行时,服务处理速度比较慢,而且有错误,因此下面的所有分析只包含方案一的测试记录。
)
(3)平均响应时间-vuser运行关联图
(4)网络和服务器时间细分
1.4、测试结果分析
Ø在500人压力下,事务执行失败率为1.91%;其中错误主要是因为:
8080连接超时
Ø事务平均响应时间较高(15s左右),说明在此压力下服务器处理速度比较慢;通过事务图和vuser图以及firstbuffer等图联合分析发现:
主要浪费时间在server端程序的事务处理上
Ø从基本测试记录中对比分析,在100、500和100并发的情况下,服务器CPU使用率一直保持在50%左右,说明信息添加模块比较消耗服务器的资源,建议优化
Ø在100人迭代的压力下,没有事务执行失败,说明在这个压力下系统仍可以正常工作,而且平均响应时间也不是很高;因此可以预见,在系统上线后很长一段时期内,使用压力仍然达不到目前压力,所以部署使用应该没有问题
2、碎片添加
2.1、测试需求
碎片添加测试页面:
:
8080/cms/UI/spec/index.jsp
测试说明:
预计初期最大用户为50个,使用时间为全天候24小时
目前设计最大支持并发为100个;应该支持300-500个用户使用
测试设计:
方案一:
500个用户在5分钟内迭代添加碎片
方案二:
100个用户在5分钟内迭代添加碎片
方案三:
采用集合点,集合100个用户进行并发,并迭代3分钟
2.2、基本测试数据记录(平均值)
事务响应时间(S)
每秒点击数
每秒HTTP请求响应数
每秒连接数
服务器CPU占有率(%)
方案一
15.76
441.704
376.821
417.293
49.378
方案二
0.094
256.821
226.607
60.301
23.727
方案三
0.096
171.809
151.569
39.963
17.318
2.3、Analysis记录结果
(1)测试结果概述
方案
事务运行总数
事务失败数
事务通过率
事务执行速率
方案一
5173
921
82.2%
13.123个/秒
方案二
2961
0
100%
15.107个/秒
方案三
1900
0
100%
10.106个/秒
(2)虚拟用户运行情况
(根据基本测试数据记录来分析,方案一运行时,服务处理速度比较慢,而且有错误,因此下面的所有分析只包含方案一的测试记录。
)
(3)平均响应时间-vuser运行关联图
(4)网络和服务器时间细分
(5)CPU使用率–用户运行关联图
2.4、测试结果分析
Ø在500人压力下事务执行失败率非常高,达17.8%;
主要错误为:
/cms/UI/sepc/channellist.faces返回500错误
/cms/UI/sepc/left.faces返回500错误
/cms/UI/top.faces返回500错误
以及上面500所影响的一些关联值无法获取造成的一系列错误
Ø事务平均响应时间较高(15s左右),说明在此压力下服务器处理速度比较慢;通过事务图和vuser图以及firstbuffer等图联合分析发现:
主要浪费时间在server端程序的事务处理上,与网络环境没有关系
Ø从基本测试记录中对比分析,在100、500和100并发的情况下,服务器CPU使用率跟随压力下降而下降,说明碎片添加模块根据压力会逐渐消耗服务器的资源,这应属于正常现象
Ø在100人迭代的压力下,没有事务执行失败,说明在这个压力下系统仍可以正常工作,而且平均响应时间也不是很高;因此可以预见,在系统上线后很长一段时期内,使用压力仍然达不到目前压力,所以部署使用应该没有问题
3、专题修改
3.1、测试需求
专题修改测试页面:
:
8080/cms/UI/subject/SubjectViewServletAction?
subId=72&editmodel=1
测试说明:
预计初期最大用户为50个,使用时间为全天候24小时
测试设计:
方案一:
200个用户在5分钟内迭代修改某一专题的一个模块内容
1.2、基本测试数据记录(平均值)
事务响应时间(S)
每秒点击数
每秒HTTP请求响应数
每秒连接数
服务器CPU占有率(%)
方案一
18.936
39.953
39.953
21.569
14.609
1.3、Analysis记录结果
(1)测试结果概述
方案
事务运行总数
事务失败数
事务通过率
事务执行速率
方案一
3380
0
100%
9.988个/秒
(2)虚拟用户运行情况
(3)平均响应时间–Vuser运行关联图
(4)网络和服务器时间细分
(5)CPU使用率–用户运行关联图
3.4、测试结果分析
Ø事务执行失败率为0,当前压力下较为稳定;
Ø事务平均响应时间非常高(18s左右),说明在此压力下服务器处理速度比较慢;通过事务图和vuser图以及firstbuffer等图联合分析发现:
主要浪费时间在server端程序的事务处理上,与网络环境没有关系
ØCPU使用率正常
4、信息签发
4.1、测试需求
签发测试地址:
http:
//211.157.5.120:
8080/makedetail/MakeDetailServlet.ms?
DBName=bjcms&MakeType=1&IIID=61
测试说明:
同【信息添加】模块
测试设计:
方案一:
300个用户在3分钟内迭代添加信息
方案二:
采用集合点,集合100个用户进行并发,并迭代3分钟
4.2、基本测试数据记录(平均值)
事务响应时间(S)
每秒点击数
每秒HTTP请求响应数
每秒连接数
服务器CPU占有率(%)
方案一
9.741
24.316
24.316
24.316
7.133
方案二
3.23
30.667
30.667
30.667
6.877
4.3、Analysis记录结果
(1)测试结果概述
方案
事务运行总数
事务失败数
事务通过率
事务执行速率
方案一
5763
64
98.89%%
24.046个/秒
方案二
5704
114
98%
30.054个/秒
(2)虚拟用户运行情况
(根据基本测试数据记录来分析,两个方案运行服务器没有问题,因此只取第一个来分析。
)
(3)平均响应时间–Vuser运行关联图
(4)网络和服务器时间细分
(5)CPU使用率–用户运行关联图
4.4、测试结果分析
Ø有部分事务执行失败率,验证发现是因为提交签发的信息不完整导致,不是问题
Ø事务平均响应时间比较正常
Ø服务器CPU使用率比较正常
Ø被测功能可以支持当前压力
5、疲劳测试
5.1、测试需求
组合压力测试的功能进行长时间的测试,保证系统在长时间运行下没有问题
测试设计:
方案一:
运行50个vuser,按照50%、30%、20%分布在【添加信息】、【添加碎片】、【修改专题】三个模块,持续运行24小时
5.2、基本测试数据记录(平均值)
事务响应时间(S)
每秒点击数
每秒HTTP请求响应数
每秒连接数
服务器CPU占有率(%)
添加信息
9.441
636.75
633.961
25.191
46.67
添加碎片
0.806
修改专题
0.384
5.3、Analysis记录结果
(1)测试结果概述
方案
事务运行总数
事务失败数
事务通过率
事务执行速率
添加信息
6486
0
100%
9.441个/秒
添加碎片
603
49
91.87%
0.806个/秒
修改专题
284
20
92.96%
0.384个/秒
(2)平均响应时间–vuser运行关联图
(3)CPU使用率–用户运行关联图
5.4测试结果分析
Ø事务执行失败率很高,ERROR记录多为相关页面500错误以及这些错误导致脚本的其他错误。
Ø测试过程中,对服务器的观察发现运行到11分钟时开始出现错误,到服务器上查看发现是web服务器连接数已经满了;建议进行连接数限制的优化
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- CMS 系统 性能 测试报告
![提示](https://static.bdocx.com/images/bang_tan.gif)