系统性能测试报告V2.0

1、“*”“*”综合信息平台（一期）综合信息平台（一期）性能测试报告性能测试报告*有限公司文件标识：文件编号：当前版本：v1.0作 者：公 司：文件状态： 草稿 正式发布 正在修改完成日期：版本控制版本控制版本号版本号作者作者参与者参与者起止日期起止日期备注备注i目 录1.文档说明文档说明 .11.1标识.11.2文档概述.11.3文档编写目的.11.4名词解释.21.5参考资料.21.6修改约束.22.项目背景项目背景 .22.1项目基本信息定义.22.2项目背景.32.3建设目标及范围.62.3.1“*”总体目标.62.3.2本期项目建设目标.92.3.3本期建设内容.92.3.4本期与“*”

2、总体规划关系.93.测试目的测试目的 .104.测试工具测试工具 .105.性能需求性能需求 .106.测试目标测试目标 .117.测试环境与配置测试环境与配置 .117.1网络环境描述.117.2测试环境描述.127.3真实环境模拟图.138.测试策略测试策略 .13测试数据准备.139.测试结果及分析测试结果及分析 .149.1一般性能测试.149.2并发测试.169.3负载测试.21ii10.性能测试总结性能测试总结 .23第 1 页1. 文档说明文档说明1.1标识标识1.文档标题文档标题2.缩略语缩略语1.2文档概述文档概述1.3文档编写目的文档编写目的性能测试的主要目的如下：验证在并

3、发连接数量达到用户所要求的正常并发连接数量时，系统的核心功能/业务的执行是否满足性能指标要求；验证并发连接数量达到最大值时，系统的运行状况；验证 j2ee 体系结构中，各层应用的性能情况，并找出性能瓶颈；验证系统在使用高峰阶段，对大数据量的处理是否正常；本文档的预期读者包括本公司项目领导、开发人员、实施人员和测试人员等项目干系人。1.4名词解释名词解释性能测试：性能测试：指为了评估软件系统的性能状况和预测软件系统性能趋势而进行的测试和分析。一般通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。响应时间：响应时间：对请求做出响应所需要的时间。并发用户数：并发用

4、户数：指同时向服务端发出请求的客户数。第 2 页吞吐量：吞吐量：单位时间内系统处理的客户请求的数量。性能计数器：性能计数器：描述服务器或操作系统性能的一些数据指标。1.5参考资料参考资料1.6修改约束修改约束该文档在正式发布后，其更新需要合作双方共同确认。第 3 页2. 项目背景项目背景项目基本信息定义项目基本信息定义2.2项目背景项目背景2.3建设目标及范围建设目标及范围“*”总体目标总体目标 近期建设目标（近期建设目标（2011-2012 年）年） 中期建设目标（中期建设目标（2013-2014 年）年） 远期建设目标（远期建设目标（2015

5、年）年） 2.3.2 本期项目建设目标本期项目建设目标2.3.3 本期建设内容本期建设内容2.3.4 本期与本期与“*”总体规划关系总体规划关系3. 测试目的测试目的1. 测试特定业务的运行情况，取得大量并发用户操作下的响应时间2. 对测试中发现的问题给出建议，如果存在性能问题，查找性能瓶颈，进行性能调优。3. 测试软件在运行过程中，运行达到用户标准值。第 4 页4. 测试工具测试工具本次性能测试主要采用 loadrunner 工具，它是一款国际主流与权威的性能测试工具，它通过录制脚本记录客户端与服务器之间的交互，然后通过回放脚本模拟出大量的虚拟用户加载到服务器上，并采用实时监控，监控服务器与

6、客户端的多项性能指标以完成对被测软件的性能评估。5. 性能需求性能需求可以借用目前使用广泛的基于 tpc-c 的经验公式，来对三个典型应用系统要求进行估算。其计算公式为：tpmctaskctsf/t(1c) 其中：task 为每日业务访问量统计峰值；ct 为系统访问集中期内访问量比例；t 为每日峰值访问时间；s 为实际业务访问操作的复杂程度比例；c 为系统主机 cpu 处理余量；f 为系统未来 10 年的访问量发展。截止到 2010 年 11 月，颐和园局域网信息接入点 260 个，联入办公网电脑 192 台，开通互联网电脑 157 台，约占总数的 82。根据以上数字统计，业务系统运行后用户总

7、数将达到 315 台，所有用户均需要访问相关的业务应用系统，按平均每个用户每天不少于 8 次访问计算，则三个典型业务应用系统的日均访问量总计不低于 2520 人次，暂按2500 人次计算。根据历史记录，高峰时期业务量约为平均业务量的 1.5 倍，三个典型业务应用系统运行后，需要充分考虑系统的可扩展性，因此，估算高峰时期的访问量约为平均访问量的 3 倍平均每次访问对应数据库事务数为 20，则task2500203150,000；访问时间大部分集中在上班时间，故取 t=6h，同时根据经验取 ct=80%；根据系统响应访问服务的分类，统计分析服务属于复杂操作，复合查询等属于一般操作，而信息检索浏览属

8、于简单操作，三个典型应用系统业务中三类操作所占比例大致为 25%、30%、45%，则根据经验权重公式：第 5 页s25%10030%1045%128.5；c 取值一般为 30%45%，参考同类型项目，取 40%；根据预测，应用平台业务年平均增长率约为 5.3%，则：f(15.3%)101.68；将上述数据带入计算公式 tpmctaskctsf/t(1c)，得：tpmc =15000080%28.51.68/660(140%) = 26600可见，三个典型应用系统的访问量与需要处理的访问事务量是非常大的，三个典型应用系统的建设是非常必要的。6. 测试目标测试目标对于专业的分析功能，提供单次访问时

9、一般地图操作 3 秒，复杂操作 5 秒的响应性能；对于基于图片引擎的访问接口，提供单次访问 1 秒以内，复杂操作 3 秒以内的相应性能。高峰时并发用户不低于 500 人。系统可同时负载 1000 用户持续半小时以上操作，系统响应一切正常。7. 测试环境测试环境与配置与配置网络环境描述网络环境描述公司内部的以太网，与服务器的连接速率为 100m，与客户端的连接速率为10/100m 自适应。 7.2测试环境描述测试环境描述服务端设设 备备硬硬 件件 配配 置置软软 件件 配配 置置web 服务器pc 机（一台）cpu：酷睿内存：64g第 6 页数据库cpu:g620 2.60hz,主频2.0ghz

10、；mem:8gb ddr3 1333/1066 mhz内存;net: 集成 intel 双千兆网卡；disk:3*300gb。sql server 2008负载产生设备pc 机（一台）cpu：酷睿 e5300内存：3gwindows xp serverloadrunner 11.00microsoft office测试地址67:8090/cas/login客户端设备名称设备名称：测试客户端测试客户端ip 地址：1用途：运行测试脚本硬件配置：cpu：e5300 内存：4gb 硬盘：400gb软件配置：操作系统：windows xp 其它：l

11、oadrunner 11.00、ie8第 7 页7.3真实环境模拟图真实环境模拟图数据库服务器建设服务器gige数据库服务器主干网门户、共享服务器园林服务器文物服务器容量为14.4tb netstor isum530 8gb光纤盘柜阵列图例8gb fc千兆以太网quantumscalar i80 物理磁带库互为镜像8gb san 交换机 16口8gb san 交换机 16口数据库系统构成双机各应用系统构成群集系统备份主服务器安装备份软件容量为14.4tb netstor isum530 8gb光纤盘柜阵列备份路径ad域服务器图 6-1 网路拓扑图8. 测试策略测试策略这次性能测试将结合用户在日

12、常工作中的实际操作情况对用户量较大的模块进行性能测试，选取公众版系统的登陆、服务访问、地图访问、查询功能作为这次性能测试的对象，并且在此基础上进行组合，设计综合场景进行性能测试。测试数据准备测试数据准备为模拟生产环境情况,设定如下基础数据：模拟用户 500 个模拟并发用户 50、100、200、300 个数据库存放 100w 条以上数据量第 8 页9. 测试结果及分析测试结果及分析9.1一般性能测试一般性能测试场景描述：场景描述：此场景测试 500 个用户访问系统的运行情况。场景设计：场景设计：每 10 秒加载登录 4 个用户，持续增加在线用户，系统成功加载 500虚拟用户在线后，所有用户在线

13、持续 5 分钟后，以每 10 秒 5 个用户退出系统。不考虑 think time。测试重点：测试重点：页面响应时间，服务器的 cpu、内存使用情况。测试结果：测试结果：服务器资源检测如下图：第 9 页说明：cpu 利用率最大值 32.552%，小于标准值 80%。磁盘驱动器读写和写入请求的最小值为 0.096%，值较小表明目前系统真实环境硬件不存在瓶颈。用户访问点击数如下图：说明：在加载到 500 个用户的时候，通过集合点使 500 个用户进行事务并发，能够看出在 500 个用户同时并发时吞吐量呈爬坡式增加，未出现其他异常情况，表明目前系统在 500 个用户并发处理不存在瓶颈。结果分析：第

14、10 页分析：在 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，平均时间为3.28s，其中 90%都小于等于 4.243s，500 个用户全部通过。9.2并发测试并

15、发测试总体描述：总体描述：500500 个用户成功加载后，分别由个用户成功加载后，分别由 5050、100100、200200、300300 用户做系统并用户做系统并发测试。发测试。场景设计：场景设计：每秒加载 5 个用户，持续增加在线用户，系统成功加载 500 虚拟用户在线后，设置登录集合点，模拟 50、100、200、300 用户并发登录系统、地图操作，采取多机联合测试、集合点策略，等待登录用户分别达到 50、100、200、300个用户时候，同时提交事务，测试 500 人在线后，同时并发 50、100、200、300 个用户时事务的通过率和响应时间，所有用户加载完后持续运行 3 分钟，以

16、每 10 秒5 个用户退出系统。不考虑 think time。第 11 页测试重点：测试重点：页面响应时间，服务器的 cpu、内存使用情况。场景一：场景一：500500 个用户成功加载后，其中个用户成功加载后，其中 5050 个用户做并发操作。个用户做并发操作。场景描述：场景描述：加载 500 个用户，其中 50 个用户并发操作情况下，对事务响应时间变化趋势和服务器资源使用情况进行统计分析。场景设计：场景设计：每 10 秒加载登录 5 个用户，持续增加在线用户，集合点加载到 50各用户开始进行并发执行事务，系统成功加载 500 虚拟用户在线后，所有用户在线持续 3 分钟后，以每 10 秒 5

17、个用户退出系统。不考虑 think time。根据如上图得到的数据信息：action_transaction 响应时间最大值 6.302s、最小值 0.203s、平均值 2.003s；processor time（processor_total）cpu 使用率最小值为 0%、最大值为 8.594%、平均值为 0.930%,符合 cpu 资源利用常规指标第 12 页（80%）；available mbytes (memory):物理内存剩余最小值为 712m、最大值996m、平均值 879.571m，符合物理内存剩余使用量大于 10%的常规指标。通过分析得出，此系统支持在设定的硬件环境下进行 5

18、0 个用户的并发运行。场景二：场景二：500500 个用户成功加载后，其中个用户成功加载后，其中 100100 个用户做并发操作。个用户做并发操作。场景描述：场景描述：加载 500 个用户，其中 100 个用户并发操作情况下，对事务响应时间变化趋势和服务器资源使用情况进行统计分析。场景设计：场景设计：每 10 秒加载登录 5 个用户，持续增加在线用户，集合点加载到 100各用户开始进行并发执行事务，系统成功加载 500 虚拟用户在线后，所有用户在线持续 3 分钟后，以每 10 秒 5 个用户退出系统。不考虑 think time。根据如上图得到的数据信息：action_transaction

19、响应时间最大值 5.024s、最小值 0.214s、平均值 2.562s；processor time（processor_total）cpu 使用率最小值为 5.729%、最大值为 25%、平均值为 13.051%,符合 cpu 资源利用常规指标（80%）；available mbytes (memory):物理内存剩余最小值为 883m、最大值984m、平均值 933.529m，符合物理内存剩余使用量大于 10%的常规指标。通过分析得出，此系统支持在设定的硬件环境下进行 100 个用户的并发运行。场景三：场景三：500500 个用户成功加载后，其中个用户成功加载后，其中 200200 个用

20、户做并发操作。个用户做并发操作。场景描述：场景描述：加载 500 个用户，其中 200 个用户并发操作情况下，对事务响应时间变化趋势和服务器资源使用情况进行统计分析。第 13 页场景设计：场景设计：每 10 秒加载登录 5 个用户，持续增加在线用户，集合点加载到 200各用户开始进行并发执行事务，系统成功加载 500 虚拟用户在线后，所有用户在线持续 3 分钟后，以每 10 秒 5 个用户退出系统。不考虑 think time。根据如上图得到的数据信息：action_transaction 响应时间最大值 4.258s、最小值 0.187s、平均值 2.956s；processor time（

21、processor_total）：cpu 使用率最小值为 0%、最大值为 57.552%、平均值为 12.625%，符合 cpu 资源利用常规指标（80%）；available mbytes (memory):物理内存剩余最小值为 529m、最大值1027m、平均值 680m，符合物理内存剩余使用量大于 10%的常规指标。通过分析得出，此系统支持在设定的硬件环境下进行 200 个用户的并发运行。场景四：场景四：500500 个用户成功加载后，其中个用户成功加载后，其中 300300 个用户做并发操作。个用户做并发操作。场景描述：场景描述：500 个用户 300 个用户的并发操作情况下，对事务响

22、应时间变化趋势和服务器资源使用情况进行统计分析。第 14 页场景设计：场景设计：每 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%,

23、符合 cpu 资源利用常规指标（80%）；available mbytes (memory):物理内存剩余最小值为 658m、最大值709m、平均值 683.706m，均符合物理内存剩余使用量大于 10%的常规指标。通过分析得出，此系统支持在设定的硬件环境下进行 300 个用户的并发运行。结果分析结果分析：交易响应时间（秒）并发用户数最小平均最大500 用户成功加载后 50 个用户做并发登录0.2032.0036.302500 用户成功加0.2032.5625.024第 15 页载后 100 个用户做并发登录500 用户成功加载后 200 个用户做并发登录0.187 2.9564.258500

24、 用户成功加载后 300 个用户做并发登录0.1873.235.2241 场景执行情况：场景执行图中，500 个虚拟用户持续并发进行系统登录、地图浏览过程中，事务响应时间与虚拟用户运行情况合并，测试时间延长并未造成系统登录事务响应时间延长。2. 硬件资源占用情况：根据分析可见，在进行 50、100、200、300 用户并发登录过程中，应用服务器平均占用率和数据库服务器平均占率均合格。9.3负载测试负载测试场景描述：场景描述：加载 1000 个用户，持续运行 30 分钟，监测事务响应时间变化趋势和服务器资源使用情况。场景设计：场景设计：每 05 秒加载登录 10 个用户，持续增加在线用户，系统成

25、功加载1000 虚拟用户在线后，所有用户在线持续 30 分钟后，以每 05 秒 2 个用户退出系统。不考虑 think time。第 16 页测试重点：测试重点：页面响应时间，服务器的 cpu、内存使用情况。测试结果：测试结果：服务器资源检测如下图：说明：cpu 利用率最大值 13.189%，小于标准值 80%。硬盘读取或写入硬盘的页数最大值为 0.332，最小值为 0.000，符合标准范围 0020,表明目前系统真实环境硬件不存在瓶颈。系统吞吐量：第 17 页说明：可以看出随着点击率越大，吞吐量随之增加，未出现其他异常情况，平均值达到 450904.284。 但是随着用户数量增大，吞吐量变化

26、却不大，随意初步推断网络宽带有所限制。9.4业务测试业务测试9.4.1 空间基础信息空间基础信息场景描述：场景描述：此场景测试 100 个用户登录系统的运行情况。场景设计：场景设计：每 15 秒加载登录 2 个用户，持续增加在线用户，系统成功加载 100虚拟用户在线后，所有用户在线持续 20 分钟后，以每 15 秒 2 个用户退出系统。不考虑 think time。第 18 页测试重点：测试重点：页面响应时间，服务器的 cpu、内存使用情况。测试结果：测试结果：服务器资源监测图：事务响应图：测试结果分析：平均事物响应时间结果：第 19 页测试结论测试结论：页面平均响应时间 0.001s；%pr

27、ocessor time 小于 80%，说明 cpu 没有瓶颈；可用物理内存数 available mbytes 的值很小（4 mb 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。当前监测值为 60829.000，系统不存在内存溢出的问题。9.4.2 古建保护与修缮管理古建保护与修缮管理场景描述：场景描述：此场景测试 100 个用户登录系统的运行情况。场景设计：场景设计：每 15 秒加载登录 2 个用户，持续增加在线用户，系统成功加载 100虚拟用户在线后，所有用户在线持续 20 分钟后，以每 15 秒 2 个用户退出系统。不考虑 think time。测试重点：测试重点：页

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

29、用户退出系统。不考虑 think time。场景设计图：第 22 页场景运行图:测试重点：测试重点：页面响应时间，服务器的 cpu、内存使用情况。测试结果：测试结果：资源监测图：平均事务响应图：第 23 页吞吐量监测图：测试结果分析：测试结论：测试结论：页面平均响应时间 0.001s，最大值为 0.003s，满足当前用户需求；%processor time 最大为 15.972 小于 75%80%，说明 cpu 没有瓶颈。%privileged time：（cpu 内核时间）是在特权模式下处理线程执行代码所花时间的百分比，如果该参数值和physical disk参数值一直很高，表明 i/o 有

30、问题。可考虑更换更快的第 24 页硬盘系统，当前监测该值最大为 0.022，说明内存硬盘无瓶颈。可用物理内存数available mbytes 的值很小（4 mb 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。当前最小值监测为 60865.000，说明系统不存在内容溢出的问题。9.4.4 文物管理展示文物管理展示场景描述：场景描述：此场景测试 100 个用户登录系统的运行情况。场景设计：场景设计：每 5 秒加载登录 2 个用户，持续增加在线用户，系统成功加载 100虚拟用户在线后，所有用户在线持续 5 分钟后，以每 5 秒 10 个用户退出系统。不考虑 think time。场景设计图：测试重点：测试重点：页面响应时间，服