系统性能测试报告V20.docx
《系统性能测试报告V20.docx》由会员分享，可在线阅读，更多相关《系统性能测试报告V20.docx（30页珍藏版）》请在冰点文库上搜索。
系统性能测试报告V20
“***”综合信息平台（一期）
性能测试报告
****有限公司
文件状态：
[]草稿
[√]正式发布
[]正在修改
文件标识：
文件编号：
当前版本：
V1.0
作者：
公司：
完成日期：
版本控制
版本号
作者
参与者
起止日期
备注
1.文档说明
1.1标识
1.文档标题
2.缩略语
1.2文档概述
1.3文档编写目的
性能测试的主要目的如下：
验证在并发连接数量达到用户所要求的正常并发连接数量时，系统的核心功能/业务的执行是否满足性能指标要求；
验证并发连接数量达到最大值时，系统的运行状况；
验证J2EE体系结构中，各层应用的性能情况，并找出性能瓶颈；
验证系统在使用高峰阶段，对大数据量的处理是否正常；
本文档的预期读者包括本公司项目领导、开发人员、实施人员和测试人员等项目干系人。
1.4名词解释
Ø性能测试：
指为了评估软件系统的性能状况和预测软件系统性能趋势而进行的测试和分析。
一般通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
Ø响应时间：
对请求做出响应所需要的时间。
Ø并发用户数：
指同时向服务端发出请求的客户数。
Ø吞吐量：
单位时间内系统处理的客户请求的数量。
性能计数器：
描述服务器或操作系统性能的一些数据指标。
1.5参考资料
1.6修改约束
该文档在正式发布后，其更新需要合作双方共同确认。
2.项目背景
2
2.1项目基本信息定义
2.2项目背景
2.3建设目标及范围
1
1.1
1.2
1.3
1.
2.
2.1
2.2
2.3
2.3.1“***”总体目标
2.3.1.1近期建设目标（2011-2012年）
2.3.1.2中期建设目标（2013-2014年）
2.3.1.3远期建设目标（2015年）
2.3.2本期项目建设目标
2.3.3本期建设内容
2.3.4本期与“***”总体规划关系
3.测试目的
1.测试特定业务的运行情况，取得大量并发用户操作下的响应时间
2.对测试中发现的问题给出建议，如果存在性能问题，查找性能瓶颈，进行性能调优。
3.测试软件在运行过程中，运行达到用户标准值。
4.测试工具
本次性能测试主要采用LoadRunner工具，它是一款国际主流与权威的性能测试工具，它通过录制脚本记录客户端与服务器之间的交互，然后通过回放脚本模拟出大量的虚拟用户加载到服务器上，并采用实时监控，监控服务器与客户端的多项性能指标以完成对被测软件的性能评估。
5.性能需求
可以借用目前使用广泛的基于TPC-C的经验公式，来对三个典型应用系统要求进行估算。
其计算公式为：
TPMC＝TASK×Ct×S×F/[T×（1－C）]
其中：
TASK为每日业务访问量统计峰值；
Ct为系统访问集中期内访问量比例；
T为每日峰值访问时间；
S为实际业务访问操作的复杂程度比例；
C为系统主机CPU处理余量；
F为系统未来10年的访问量发展。
截止到2010年11月，颐和园局域网信息接入点260个，联入办公网电脑192台，开通互联网电脑157台，约占总数的82％。
根据以上数字统计，业务系统运行后用户总数将达到315台，所有用户均需要访问相关的业务应用系统，按平均每个用户每天不少于8次访问计算，则三个典型业务应用系统的日均访问量总计不低于2520人次，暂按2500人次计算。
根据历史记录，高峰时期业务量约为平均业务量的1.5倍，三个典型业务应用系统运行后，需要充分考虑系统的可扩展性，因此，估算高峰时期的访问量约为平均访问量的3倍平均每次访问对应数据库事务数为20，则
TASK＝2500×20×3＝150,000；
访问时间大部分集中在上班时间，故取T=6h，同时根据经验取Ct=80%；
根据系统响应访问服务的分类，统计分析服务属于复杂操作，复合查询等属于一般操作，而信息检索浏览属于简单操作，三个典型应用系统业务中三类操作所占比例大致为25%、30%、45%，则根据经验权重公式：
S＝25%×100＋30%×10＋45%×1＝28.5；
C取值一般为30%～45%，参考同类型项目，取40%；
根据预测，应用平台业务年平均增长率约为5.3%，则：
F＝（1＋5.3%）10≈1.68；
将上述数据带入计算公式TPMC＝TASK×Ct×S×F/[T×（1－C）]，得：
TPMC=150000×80%×28.5×1.68/[6×60×（1－40%）]=26600
可见，三个典型应用系统的访问量与需要处理的访问事务量是非常大的，三个典型应用系统的建设是非常必要的。
6.测试目标
对于专业的分析功能，提供单次访问时一般地图操作3秒，复杂操作5秒的响应性能；对于基于图片引擎的访问接口，提供单次访问1秒以内，复杂操作3秒以内的相应性能。
高峰时并发用户不低于500人。
系统可同时负载1000用户持续半小时以上操作，系统响应一切正常。
7.测试环境与配置
1
2
3
4
5
6
7
7.1网络环境描述
公司内部的以太网，与服务器的连接速率为100M，与客户端的连接速率为10/100M自适应。
7.2测试环境描述
●服务端
设备
硬件配置
软件配置
Web服务器
PC机（一台）
CPU：
酷睿
内存：
64G
数据库
CPU:
G620@2.60Hz,主频≥2.0GHz；
MEM:
8GBDDR31333/1066MHz内存;
NET:
集成Intel双千兆网卡；DISK:
3*300GB。
SQLServer2008
负载产生设备
PC机（一台）
CPU：
酷睿E5300
内存：
3G
WindowsXPserver
LoadRunner11.00
MicrosoftOffice
测试地址
http:
//192.168.1.167:
8090/cas/login
●客户端
设备名称：
测试客户端
IP地址：
192.168.1.31
用途：
运行测试脚本
硬件配置：
CPU：
E5300
内存：
4GB
硬盘：
400GB
软件配置：
操作系统：
WindowsXP
其它：
LoadRunner11.00、IE8
7.3真实环境模拟图
图6-1网路拓扑图
8.测试策略
这次性能测试将结合用户在日常工作中的实际操作情况对用户量较大的模块进行性能测试，选取公众版系统的登陆、服务访问、地图访问、查询功能作为这次性能测试的对象，并且在此基础上进行组合，设计综合场景进行性能测试。
测试数据准备
为模拟生产环境情况,设定如下基础数据：
Ø模拟用户500个
Ø模拟并发用户50、100、200、300个
Ø数据库存放100W条以上数据量
9.测试结果及分析
1
2
3
4
5
6
7
8
9
9.1一般性能测试
场景描述：
此场景测试500个用户访问系统的运行情况。
场景设计：
每10秒加载登录4个用户，持续增加在线用户，系统成功加载500虚拟用户在线后，所有用户在线持续5分钟后，以每10秒5个用户退出系统。
不考虑ThinkTime。
测试重点：
页面响应时间，服务器的CPU、内存使用情况。
测试结果：
服务器资源检测如下图：
说明：
CPU利用率最大值32.552%，小于标准值80%。
磁盘驱动器读写和写入请求的最小值为0.096%，值较小表明目前系统真实环境硬件不存在瓶颈。
用户访问点击数如下图：
说明：
在加载到500个用户的时候，通过集合点使500个用户进行事务并发，能够看出在500个用户同时并发时吞吐量呈爬坡式增加，未出现其他异常情况，表明目前系统在500个用户并发处理不存在瓶颈。
结果分析：
分析：
在500个用户运行的情况下，系统的总吞吐量达到27,800,954,406bytes；平均每秒吞吐量11,497,500bytes；总点击次数2,132,992次；平均每秒点击次数882.131次；VuserendTransaction,VuserinitTransaction是系统默认的事务，ActiongTransaction是录制时进行操作的事务，我们可以看到500个用户运行事务时，最短的时间为0.465s，最长时间为5.125s，平均时间为3.28s，其中90%都小于等于4.243s，500个用户全部通过。
9.2并发测试
总体描述：
500个用户成功加载后，分别由50、100、200、300用户做系统并发测试。
场景设计：
每秒加载5个用户，持续增加在线用户，系统成功加载500虚拟用户在线后，设置登录集合点，模拟50、100、200、300用户并发登录系统、地图操作，采取多机联合测试、集合点策略，等待登录用户分别达到50、100、200、300个用户时候，同时提交事务，测试500人在线后，同时并发50、100、200、300个用户时事务的通过率和响应时间，所有用户加载完后持续运行3分钟，以每10秒5个用户退出系统。
不考虑ThinkTime。
测试重点：
页面响应时间，服务器的CPU、内存使用情况。
场景一：
500个用户成功加载后，其中50个用户做并发操作。
场景描述：
加载500个用户，其中50个用户并发操作情况下，对事务响应时间变化趋势和服务器资源使用情况进行统计分析。
场景设计：
每10秒加载登录5个用户，持续增加在线用户，集合点加载到50各用户开始进行并发执行事务，系统成功加载500虚拟用户在线后，所有用户在线持续3分钟后，以每10秒5个用户退出系统。
不考虑ThinkTime。
根据如上图得到的数据信息：
Action_Transaction响应时间最大值6.302s、最小值0.203s、平均值2.003s；ProcessorTime（Processor_Total）CPU使用率最小值为0%、最大值为8.594%、平均值为0.930%,符合CPU资源利用常规指标（<80%）；AvailableMbytes（Memory）:
物理内存剩余最小值为712M、最大值996M、平均值879.571M，符合物理内存剩余使用量大于10%的常规指标。
通过分析得出，此系统支持在设定的硬件环境下进行50个用户的并发运行。
场景二：
500个用户成功加载后，其中100个用户做并发操作。
场景描述：
加载500个用户，其中100个用户并发操作情况下，对事务响应时间变化趋势和服务器资源使用情况进行统计分析。
场景设计：
每10秒加载登录5个用户，持续增加在线用户，集合点加载到100各用户开始进行并发执行事务，系统成功加载500虚拟用户在线后，所有用户在线持续3分钟后，以每10秒5个用户退出系统。
不考虑ThinkTime。
根据如上图得到的数据信息：
Action_Transaction响应时间最大值5.024s、最小值0.214s、平均值2.562s；ProcessorTime（Processor_Total）CPU使用率最小值为5.729%、最大值为25%、平均值为13.051%,符合CPU资源利用常规指标（<80%）；AvailableMbytes（Memory）:
物理内存剩余最小值为883M、最大值984M、平均值933.529M，符合物理内存剩余使用量大于10%的常规指标。
通过分析得出，此系统支持在设定的硬件环境下进行100个用户的并发运行。
场景三：
500个用户成功加载后，其中200个用户做并发操作。
场景描述：
加载500个用户，其中200个用户并发操作情况下，对事务响应时间变化趋势和服务器资源使用情况进行统计分析。
场景设计：
每10秒加载登录5个用户，持续增加在线用户，集合点加载到200各用户开始进行并发执行事务，系统成功加载500虚拟用户在线后，所有用户在线持续3分钟后，以每10秒5个用户退出系统。
不考虑ThinkTime。
根据如上图得到的数据信息：
Action_Transaction响应时间最大值4.258s、最小值0.187s、平均值2.956s；ProcessorTime（Processor_Total）：
CPU使用率最小值为0%、最大值为57.552%、平均值为12.625%，符合CPU资源利用常规指标（<80%）；AvailableMbytes（Memory）:
物理内存剩余最小值为529M、最大值1027M、平均值680M，符合物理内存剩余使用量大于10%的常规指标。
通过分析得出，此系统支持在设定的硬件环境下进行200个用户的并发运行。
场景四：
500个用户成功加载后，其中300个用户做并发操作。
场景描述：
500个用户300个用户的并发操作情况下，对事务响应时间变化趋势和服务器资源使用情况进行统计分析。
场景设计：
每10秒加载登录5个用户，持续增加在线用户，集合点加载到300用户开始进行并发执行事务，系统成功加载500虚拟用户在线后，所有用户在线持续3分钟后，以每10秒5个用户退出系统。
不考虑ThinkTime。
根据如上图得到的数据信息：
Action_Transaction响应时间最大值5.224s、最小值0.187s、平均值3.23s；ProcessorTime（Processor_Total）CPU使用率最小值为1.042%、最大值为79.688%、平均值为34.466%,符合CPU资源利用常规指标（<80%）；AvailableMbytes（Memory）:
物理内存剩余最小值为658M、最大值709M、平均值683.706M，均符合物理内存剩余使用量大于10%的常规指标。
通过分析得出，此系统支持在设定的硬件环境下进行300个用户的并发运行。
结果分析：
并发用户数
交易响应时间（秒）
最小
平均
最大
500用户成功加载后50个用户做并发登录
0.203
2.003
6.302
500用户成功加载后100个用户做并发登录
0.203
2.562
5.024
500用户成功加载后200个用户做并发登录
0.187
2.956
4.258
500用户成功加载后300个用户做并发登录
0.187
3.23
5.224
1．场景执行情况：
场景执行图中，500个虚拟用户持续并发进行系统登录、地图浏览过程中，事务响应时间与虚拟用户运行情况合并，测试时间延长并未造成系统登录事务响应时间延长。
2.硬件资源占用情况：
根据分析可见，在进行50、100、200、300用户并发登录过程中，应用服务器平均占用率和数据库服务器平均占率均合格。
9.3负载测试
场景描述：
加载1000个用户，持续运行30分钟，监测事务响应时间变化趋势和服务器资源使用情况。
场景设计：
每05秒加载登录10个用户，持续增加在线用户，系统成功加载1000虚拟用户在线后，所有用户在线持续30分钟后，以每05秒2个用户退出系统。
不考虑ThinkTime。
测试重点：
页面响应时间，服务器的CPU、内存使用情况。
测试结果：
服务器资源检测如下图：
说明：
CPU利用率最大值13.189%，小于标准值80%。
硬盘读取或写入硬盘的页数最大值为0.332，最小值为0.000，符合标准范围00~20,表明目前系统真实环境硬件不存在瓶颈。
系统吞吐量：
说明：
可以看出随着点击率越大，吞吐量随之增加，未出现其他异常情况，平均值达到450904.284。
但是随着用户数量增大，吞吐量变化却不大，随意初步推断网络宽带有所限制。
9.4业务测试
9.4.1空间基础信息
场景描述：
此场景测试100个用户登录系统的运行情况。
场景设计：
每15秒加载登录2个用户，持续增加在线用户，系统成功加载100虚拟用户在线后，所有用户在线持续20分钟后，以每15秒2个用户退出系统。
不考虑ThinkTime。
测试重点：
页面响应时间，服务器的CPU、内存使用情况。
测试结果：
服务器资源监测图：
事务响应图：
测试结果分析：
平均事物响应时间结果：
测试结论：
页面平均响应时间0.001s；%ProcessorTime小于80%，说明CPU没有瓶颈；可用物理内存数AvailableMbytes的值很小（4MB或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。
当前监测值为60829.000，系统不存在内存溢出的问题。
9.4.2古建保护与修缮管理
场景描述：
此场景测试100个用户登录系统的运行情况。
场景设计：
每15秒加载登录2个用户，持续增加在线用户，系统成功加载100虚拟用户在线后，所有用户在线持续20分钟后，以每15秒2个用户退出系统。
不考虑ThinkTime。
测试重点：
页面响应时间，服务器的CPU、内存使用情况。
测试结果：
吞吐量监测图：
事务响应时间监测图：
资源监测图：
测试结果分析：
平均事务响应图：
测试结论：
页面平均响应时间0.001s，最大值为0.002s，满足当前用户需求；%ProcessorTime小于80%，说明CPU没有瓶颈。
9.4.3园林景观管理系统
场景描述：
此场景测试100个用户登录系统的运行情况。
场景设计：
每15秒加载登录2个用户，持续增加在线用户，系统成功加载100虚拟用户在线后，所有用户在线持续10分钟后，以每15秒2个用户退出系统。
不考虑ThinkTime。
场景设计图：
场景运行图:
测试重点：
页面响应时间，服务器的CPU、内存使用情况。
测试结果：
资源监测图：
平均事务响应图：
吞吐量监测图：
测试结果分析：
测试结论：
页面平均响应时间0.001s，最大值为0.003s，满足当前用户需求；%ProcessorTime最大为15.972小于75%——80%，说明CPU没有瓶颈。
%PrivilegedTime：
（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比，如果该参数值和"PhysicalDisk"参数值一直很高，表明I/O有问题。
可考虑更换更快的硬盘系统，当前监测该值最大为0.022，说明内存硬盘无瓶颈。
可用物理内存数AvailableMbytes的值很小（4MB或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。
当前最小值监测为60865.000，说明系统不存在内容溢出的问题。
9.4.4文物管理展示
场景描述：
此场景测试100个用户登录系统的运行情况。
场景设计：
每5秒加载登录2个用户，持续增加在线用户，系统成功加载100虚拟用户在线后，所有用户在线持续5分钟后，以每5秒10个用户退出系统。
不考虑ThinkTime。
场景设计图：
测试重点：
页面响应时间，服务器的CPU、内存使用情况。
测试结果：
资源监测图：
测试结果分析：
吞吐量监测图：
平均事务响应时间监测图：
测试结论：
随着点击率越大，吞吐量随之增加，未出现其他异常情况，平均值达到5044443.175。
平均事务响应时间是0.001s，满足当前用户需求。
%PrivilegedTime：
（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比，如果该值一直很高，表明I/O有问题。
当前值为0.369，所以当前硬盘系统无瓶颈。
9.4.5门户
场景描述：
此场景测试100个用户登录系统的运行情况。
场景设计：
每5秒加载登录10个用户，持续增加在线用户，系统成功加载100虚拟用户在线后，所有用户在线持续5分钟后，以每5秒10个用户退出系统。
不考虑ThinkTime。
场景设计图：
场景运行图：
测试重点：
页面响应时间，服务器的CPU、内存使用情况。
测试结果：
资源监测图：
事务响应图：
吞吐量监测图：
结果分析：
测试结论：
事务响应时间最大为0.035s，%ProcessorTime最大为0.087小于75%——80%，说明CPU没有瓶颈。
随着点击率越大，吞吐量随之增加，未出现其他异常情况，平均值达到9.314.898.211。
读取和写入请求Avg.DiskQueueLength（为所选磁盘在实例间隔中列队的）的平均数为0.032，当前该值未超过磁盘数的1.5~2倍磁盘不存在瓶颈。
10.性能测试总结
1.本次测试是在客户真实使用环境下进行监测的，对被测系统模拟了五个业务简单场景和三个复杂场景、四个超强度的并发测试场景进行了监测，主要监测了响应速率、资源耗费情况等以及对系统瓶颈等进行分析。
测试过程中有100w条以上数据支撑，完全符合客户后期使用的支撑环境。
2.实时监测过程数据逐渐增加，数据量庞大，目前并未出现磁盘空间的限制遏制软件性能的提高问题。
性能将非常卓越，完全可以满足任何日常生产时的性能需求！
3.特殊场景，当模拟1000用户进行负载强度测试时，持续访问系统时，随着用户数量增大，吞吐量变化却不大，初步推断网络宽带有所限制。
如果想使性能更卓越，后期用户使用较多时，可提升带宽。
升级会员 