系统性能测试报告V20

1、“*”综合信息平台（一期）性能测试报告*有限公司文件状态： 草稿 正式发布 正在修改文件标识：文件编号：当前版本：V1.0作 者：公 司：完成日期：版本控制版本号作者参与者起止日期备注目 录1.文档说明11.1标识11.2文档概述11.3文档编写目的11.4名词解释21.5参考资料21.6修改约束22.项目背景22.1项目基本信息定义22.2项目背景32.3建设目标及范围6“*”总体目标6本期项目建设目标9本期建设内容9本期与“*”总体规划关系93.测试目的104.测试工具105.性能需求106.测试目标117.测试环境与配置117.1网络环境描述117.2测试环境描述127.3真实环境模拟图

2、138.测试策略13测试数据准备139.测试结果及分析149.1一般性能测试149.2并发测试169.3负载测试2110.性能测试总结231. 文档说明1.1 标识1.文档标题2.缩略语1.2 文档概述1.3 文档编写目的性能测试的主要目的如下：l 验证在并发连接数量达到用户所要求的正常并发连接数量时，系统的核心功能/业务的执行是否满足性能指标要求；l 验证并发连接数量达到最大值时，系统的运行状况；l 验证J2EE体系结构中，各层应用的性能情况，并找出性能瓶颈；l 验证系统在使用高峰阶段，对大数据量的处理是否正常；l 本文档的预期读者包括本公司项目领导、开发人员、实施人员和测试人员等项目干系人

3、。1.4 名词解释Ø 性能测试：指为了评估软件系统的性能状况和预测软件系统性能趋势而进行的测试和分析。一般通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。Ø 响应时间：对请求做出响应所需要的时间。Ø 并发用户数：指同时向服务端发出请求的客户数。Ø 吞吐量：单位时间内系统处理的客户请求的数量。性能计数器：描述服务器或操作系统性能的一些数据指标。1.5 参考资料1.6 修改约束该文档在正式发布后，其更新需要合作双方共同确认。2. 项目背景22.1 项目基本信息定义2.2 项目背景2.3 建设目标及范围

4、.1 “*”总体目标 近期建设目标（2011-2012年） 中期建设目标（2013-2014年） 远期建设目标（2015 年） 2.3.2 本期项目建设目标2.3.3 本期建设内容2.3.4 本期与“*”总体规划关系3. 测试目的1. 测试特定业务的运行情况，取得大量并发用户操作下的响应时间2. 对测试中发现的问题给出建议，如果存在性能问题，查找性能瓶颈，进行性能调优。3. 测试软件在运行过程中，运行达到用户标准值。4. 测试工具本次性能测试主要采用LoadRunner工具，它是一款国际主流与权威的性能测试工具，它通

5、过录制脚本记录客户端与服务器之间的交互，然后通过回放脚本模拟出大量的虚拟用户加载到服务器上，并采用实时监控，监控服务器与客户端的多项性能指标以完成对被测软件的性能评估。5. 性能需求可以借用目前使用广泛的基于TPC-C的经验公式，来对三个典型应用系统要求进行估算。其计算公式为：TPMCTASK×Ct×S×F/T×(1C) 其中：TASK为每日业务访问量统计峰值；Ct为系统访问集中期内访问量比例；T为每日峰值访问时间；S为实际业务访问操作的复杂程度比例；C为系统主机CPU处理余量；F为系统未来10年的访问量发展。截止到2010年11月，颐和园局域网信息接入

6、点260个，联入办公网电脑192台，开通互联网电脑157台，约占总数的82。根据以上数字统计，业务系统运行后用户总数将达到315台，所有用户均需要访问相关的业务应用系统，按平均每个用户每天不少于8次访问计算，则三个典型业务应用系统的日均访问量总计不低于2520人次，暂按2500人次计算。根据历史记录，高峰时期业务量约为平均业务量的1.5倍，三个典型业务应用系统运行后，需要充分考虑系统的可扩展性，因此，估算高峰时期的访问量约为平均访问量的3倍平均每次访问对应数据库事务数为20，则TASK2500×20×3150,000；访问时间大部分集中在上班时间，故取T=6h，同时根据经验

7、取Ct=80%；根据系统响应访问服务的分类，统计分析服务属于复杂操作，复合查询等属于一般操作，而信息检索浏览属于简单操作，三个典型应用系统业务中三类操作所占比例大致为25%、30%、45%，则根据经验权重公式：S25%×10030%×1045%×128.5；C取值一般为30%45%，参考同类型项目，取40%；根据预测，应用平台业务年平均增长率约为5.3%，则：F(15.3%)101.68；将上述数据带入计算公式TPMCTASK×Ct×S×F/T×(1C)，得：TPMC =150000×80%×28.5&#

8、215;1.68/6×60×(140%) = 26600可见，三个典型应用系统的访问量与需要处理的访问事务量是非常大的，三个典型应用系统的建设是非常必要的。6. 测试目标对于专业的分析功能，提供单次访问时一般地图操作3秒，复杂操作5秒的响应性能；对于基于图片引擎的访问接口，提供单次访问1 秒以内，复杂操作3 秒以内的相应性能。高峰时并发用户不低于500 人。系统可同时负载1000用户持续半小时以上操作，系统响应一切正常。7. 测试环境与配置12345677.1 网络环境描述公司内部的以太网，与服务器的连接速率为100M，与客户端的连接速率为10/100M自适应。 7.2 测

9、试环境描述l 服务端设 备硬 件 配 置软 件 配 置Web服务器PC机（一台）CPU：酷睿内存：64G数据库CPU:G620 2.60Hz,主频2.0GHz；MEM:8GB DDR3 1333/1066 MHz内存;NET: 集成Intel 双千兆网卡；DISK:3*300GB。SQL Server 2008负载产生设备PC机（一台）CPU：酷睿E5300内存：3GWindows XP serverLoadRunner 11.00Microsoft Office测试地址http:/:8090/cas/loginl 客户端设备名称：测试客户端IP 地址：1用途：运行测试脚

10、本硬件配置：CPU：E5300 内存：4GB 硬盘：400GB软件配置：操作系统：Windows XP 其它：LoadRunner 11.00、IE87.3 真实环境模拟图图6-1 网路拓扑图8. 测试策略这次性能测试将结合用户在日常工作中的实际操作情况对用户量较大的模块进行性能测试，选取公众版系统的登陆、服务访问、地图访问、查询功能作为这次性能测试的对象，并且在此基础上进行组合，设计综合场景进行性能测试。测试数据准备为模拟生产环境情况,设定如下基础数据：Ø 模拟用户500个Ø 模拟并发用户50、100、200、300个Ø 数据库存放100W条以上数据量9. 测试

11、结果及分析1234567899.1 一般性能测试场景描述：此场景测试500个用户访问系统的运行情况。场景设计：每10秒加载登录4个用户，持续增加在线用户，系统成功加载500虚拟用户在线后，所有用户在线持续5分钟后，以每10秒5个用户退出系统。不考虑Think Time。测试重点：页面响应时间，服务器的CPU、内存使用情况。测试结果：服务器资源检测如下图：说明：CPU利用率最大值32.552%，小于标准值80%。磁盘驱动器读写和写入请求的最小值为0.096%，值较小表明目前系统真实环境硬件不存在瓶颈。用户访问点击数如下图：说明：在加载到500个用户的时候，通过集合点使500个用户进行事务并发，能

12、够看出在500个用户同时并发时吞吐量呈爬坡式增加，未出现其他异常情况，表明目前系统在500个用户并发处理不存在瓶颈。结果分析：分析：在500个用户运行的情况下，系统的总吞吐量达到27,800,954,406 bytes；平均每秒吞吐量11,497,500 bytes；总点击次数2,132,992次；平均每秒点击次数882.131次；Vuser end Transaction , Vuser init Transaction是系统默认的事务，Actiong Transaction是录制时进行操作的事务，我们可以看到500个用户运行事务时，最短的时间为0.465s，最长时间为5.125s，平均时间

13、为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个用户退出系统。不考虑Think

14、 Time。测试重点：页面响应时间，服务器的CPU、内存使用情况。场景一：500个用户成功加载后，其中50个用户做并发操作。场景描述：加载500个用户，其中50个用户并发操作情况下，对事务响应时间变化趋势和服务器资源使用情况进行统计分析。场景设计：每10秒加载登录5个用户，持续增加在线用户，集合点加载到50各用户开始进行并发执行事务，系统成功加载500虚拟用户在线后，所有用户在线持续3分钟后，以每10秒5个用户退出系统。不考虑Think Time。根据如上图得到的数据信息：Action_Transaction响应时间最大值6.302s、最小值0.203s、平均值2.003s；Processor

15、 Time（Processor_Total）CPU使用率最小值为0%、最大值为8.594%、平均值为0.930%,符合CPU资源利用常规指标（<80%）；Available Mbytes (Memory):物理内存剩余最小值为712M、最大值996M、平均值879.571M，符合物理内存剩余使用量大于10%的常规指标。通过分析得出，此系统支持在设定的硬件环境下进行50个用户的并发运行。场景二：500个用户成功加载后，其中100个用户做并发操作。场景描述：加载500个用户，其中100个用户并发操作情况下，对事务响应时间变化趋势和服务器资源使用情况进行统计分析。场景设计：每10秒加载登录5个

16、用户，持续增加在线用户，集合点加载到100各用户开始进行并发执行事务，系统成功加载500虚拟用户在线后，所有用户在线持续3分钟后，以每10秒5个用户退出系统。不考虑Think Time。根据如上图得到的数据信息：Action_Transaction响应时间最大值5.024s、最小值0.214s、平均值 2.562s；Processor Time（Processor_Total）CPU使用率最小值为5.729%、最大值为25%、平均值为13.051%,符合CPU资源利用常规指标（<80%）；Available Mbytes (Memory):物理内存剩余最小值为883M、最大值984M、平

17、均值933.529M，符合物理内存剩余使用量大于10%的常规指标。通过分析得出，此系统支持在设定的硬件环境下进行100个用户的并发运行。场景三：500个用户成功加载后，其中200个用户做并发操作。场景描述：加载500个用户，其中200个用户并发操作情况下，对事务响应时间变化趋势和服务器资源使用情况进行统计分析。场景设计：每10秒加载登录5个用户，持续增加在线用户，集合点加载到200各用户开始进行并发执行事务，系统成功加载500虚拟用户在线后，所有用户在线持续3分钟后，以每10秒5个用户退出系统。不考虑Think Time。根据如上图得到的数据信息：Action_Transaction响应时间最

18、大值4.258s、最小值0.187s、平均值2.956s；Processor Time（Processor_Total）：CPU使用率最小值为0%、最大值为57.552%、平均值为12.625%，符合CPU资源利用常规指标（<80%）；Available Mbytes (Memory):物理内存剩余最小值为529M、最大值1027M、平均值680M，符合物理内存剩余使用量大于10%的常规指标。通过分析得出，此系统支持在设定的硬件环境下进行200个用户的并发运行。场景四：500个用户成功加载后，其中300个用户做并发操作。场景描述：500个用户300个用户的并发操作情况下，对事务响应时间变

19、化趋势和服务器资源使用情况进行统计分析。场景设计：每10秒加载登录5个用户，持续增加在线用户，集合点加载到300用户开始进行并发执行事务，系统成功加载500虚拟用户在线后，所有用户在线持续3分钟后，以每10秒5个用户退出系统。不考虑Think Time。根据如上图得到的数据信息：Action_Transaction响应时间最大值5.224s、最小值0.187s、平均值3.23s；Processor Time（Processor_Total）CPU使用率最小值为1.042%、最大值为79.688%、平均值为34.466%,符合CPU资源利用常规指标（<80%）；Available Mbyt

20、es (Memory):物理内存剩余最小值为658M、最大值709M、平均值683.706M，均符合物理内存剩余使用量大于10%的常规指标。通过分析得出，此系统支持在设定的硬件环境下进行300个用户的并发运行。结果分析：并发用户数交易响应时间（秒）最小平均最大500用户成功加载后50个用户做并发登录0.2032.0036.302500用户成功加载后100个用户做并发登录0.2032.5625.024500用户成功加载后200个用户做并发登录0.187 2.9564.258500用户成功加载后300个用户做并发登录0.1873.235.2241 场景执行情况：场景执行图中，500个虚拟用户持续并

21、发进行系统登录、地图浏览过程中，事务响应时间与虚拟用户运行情况合并，测试时间延长并未造成系统登录事务响应时间延长。2.硬件资源占用情况：根据分析可见，在进行50、100、200、300用户并发登录过程中，应用服务器平均占用率和数据库服务器平均占率均合格。9.3 负载测试场景描述：加载1000个用户，持续运行30分钟，监测事务响应时间变化趋势和服务器资源使用情况。场景设计：每05秒加载登录10个用户，持续增加在线用户，系统成功加载1000虚拟用户在线后，所有用户在线持续30分钟后，以每05秒2个用户退出系统。不考虑Think Time。测试重点：页面响应时间，服务器的CPU、内存使用情况。测试结

22、果：服务器资源检测如下图：说明：CPU利用率最大值13.189%，小于标准值80%。硬盘读取或写入硬盘的页数最大值为0.332，最小值为0.000，符合标准范围0020,表明目前系统真实环境硬件不存在瓶颈。系统吞吐量：说明：可以看出随着点击率越大，吞吐量随之增加，未出现其他异常情况，平均值达到450904.284。 但是随着用户数量增大，吞吐量变化却不大，随意初步推断网络宽带有所限制。9.4 业务测试9.4.1 空间基础信息场景描述：此场景测试100个用户登录系统的运行情况。场景设计：每15秒加载登录2个用户，持续增加在线用户，系统成功加载100虚拟用户在线后，所有用户在线持续20分钟后，以每

23、15秒2个用户退出系统。不考虑Think Time。测试重点：页面响应时间，服务器的CPU、内存使用情况。测试结果：服务器资源监测图：事务响应图：测试结果分析：平均事物响应时间结果：测试结论：页面平均响应时间0.001s；%Processor Time小于80%，说明CPU没有瓶颈；可用物理内存数Available Mbytes 的值很小（4 MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。当前监测值为60829.000，系统不存在内存溢出的问题。9.4.2 古建保护与修缮管理场景描述：此场景测试100个用户登录系统的运行情况。场景设计：每15秒加载登录2个用户，持续增加

24、在线用户，系统成功加载100虚拟用户在线后，所有用户在线持续20分钟后，以每15秒2个用户退出系统。不考虑Think Time。测试重点：页面响应时间，服务器的CPU、内存使用情况。测试结果：吞吐量监测图：事务响应时间监测图：资源监测图：测试结果分析：平均事务响应图：测试结论：页面平均响应时间0.001s，最大值为0.002s，满足当前用户需求；%Processor Time小于80%，说明CPU没有瓶颈。9.4.3 园林景观管理系统场景描述：此场景测试100个用户登录系统的运行情况。场景设计：每15秒加载登录2个用户，持续增加在线用户，系统成功加载100虚拟用户在线后，所有用户在线持续10分

25、钟后，以每15秒2个用户退出系统。不考虑Think Time。场景设计图：场景运行图:测试重点：页面响应时间，服务器的CPU、内存使用情况。测试结果：资源监测图：平均事务响应图：吞吐量监测图：测试结果分析：测试结论：页面平均响应时间0.001s，最大值为0.003s，满足当前用户需求；%Processor Time最大为15.972小于75%80%，说明CPU没有瓶颈。%Privileged Time：（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比，如果该参数值和"Physical Disk"参数值一直很高，表明I/O 有问题。可考虑更换更快的硬盘系统，当前监测该值最大为0.022，说明内存硬盘无瓶颈。可用物理内存数Available Mbytes 的值很小（4 MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。当前最小值监测为60865.000，说明系统不存在内容溢出的问题。9.4.4 文物管理展示场景描述：此场景测试100个用户登录系统的运行情况。场景设计：每5秒加载登录2个用户，持续增加在线用户，系统成功加载100虚拟用户在线后，所有用户在线持续5分钟后，以每5秒10个用户退出系统。不考虑Think Time。场景设计图：测试重点：页面响应时间，服务器的CPU、内存使用情况。测试结果：资