系统性能测试报告V2.0

1、“*”“*”综合信息平台（一期）综合信息平台（一期） 性能测试报告性能测试报告 *有限公司 文件标识： 文件编号： 当前版本：v1.0 作 者： 公 司： 文件状态： 草稿 正式发布 正在修改 完成日期： 版本控制版本控制 版本号版本号作者作者参与者参与者起止日期起止日期备注备注 目 录 1.文档说明文档说明 .1 1.1标识.1 1.2文档概述.1 1.3文档编写目的.1 1.4名词解释.2 1.5参考资料.2 1.6修改约束.2 2.项目背景项目背景 .2 2.1项目基本信息定义.2 2.2项目背景.3 2.3建设目标及范围.6 2.3.1“*”总体目标.6 2.3.2本期项目建设目标.9

2、 2.3.3本期建设内容.9 2.3.4本期与“*”总体规划关系.9 3.测试目的测试目的 .10 4.测试工具测试工具 .10 5.性能需求性能需求 .10 6.测试目标测试目标 .11 7.测试环境与配置测试环境与配置 .11 7.1网络环境描述.11 7.2测试环境描述.12 7.3真实环境模拟图.13 8.测试策略测试策略 .13 测试数据准备.13 9.测试结果及分析测试结果及分析 .14 9.1一般性能测试.14 9.2并发测试.16 9.3负载测试.21 10.性能测试总结性能测试总结 .23 1. 文档说明文档说明 1.1标识标识 1.文档标题文档标题 2.缩略语缩略语 1.2

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

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

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

6、工具，它通过录制脚本记录客户端与服务器之间的交互，然后通过回放脚本模 拟出大量的虚拟用户加载到服务器上，并采用实时监控，监控服务器与客户端的多 项性能指标以完成对被测软件的性能评估。 5. 性能需求性能需求 可以借用目前使用广泛的基于 tpc-c 的经验公式，来对三个典型应用系统要求进 行估算。其计算公式为： tpmctaskctsf/t(1c) 其中：task 为每日业务访问量统计峰值； ct 为系统访问集中期内访问量比例； t 为每日峰值访问时间； s 为实际业务访问操作的复杂程度比例； c 为系统主机 cpu 处理余量； f 为系统未来 10 年的访问量发展。 截止到 2010 年 11

7、 月，颐和园局域网信息接入点 260 个，联入办公网电脑 192 台， 开通互联网电脑 157 台，约占总数的 82。根据以上数字统计，业务系统运行后用户总 数将达到 315 台，所有用户均需要访问相关的业务应用系统，按平均每个用户每天不少 于 8 次访问计算，则三个典型业务应用系统的日均访问量总计不低于 2520 人次，暂按 2500 人次计算。根据历史记录，高峰时期业务量约为平均业务量的 1.5 倍，三个典型业 务应用系统运行后，需要充分考虑系统的可扩展性，因此，估算高峰时期的访问量约为 平均访问量的 3 倍平均每次访问对应数据库事务数为 20，则 task2500203150,000；

8、访问时间大部分集中在上班时间，故取 t=6h，同时根据经验取 ct=80%； 根据系统响应访问服务的分类，统计分析服务属于复杂操作，复合查询等属于一般 操作，而信息检索浏览属于简单操作，三个典型应用系统业务中三类操作所占比例大致 为 25%、30%、45%，则根据经验权重公式： 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

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

10、环境描述测试环境描述 服务端 设设 备备硬硬 件件 配配 置置软软 件件 配配 置置 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 内存：3g windows xp server loadrunner 11.00 microsoft office 测试地址 67:8

11、090/cas/login 客户端 设备名称设备名称：测试客户端测试客户端 ip 地址：1 用途：运行测试脚本 硬件配置： cpu：e5300 内存：4gb 硬盘：400gb 软件配置： 操作系统：windows xp 其它：loadrunner 11.00、ie8 7.3真实环境模拟图真实环境模拟图 数据库服务器 建设服务器 gige 数据库服务器 主干网 门户、共享服 务器 园林服务器 文物服务器 容量为14.4tb netstor isum530 8gb光纤盘柜阵列 图例 8gb fc 千兆以太网 quantum scalar i80 物 理磁带库 互为镜像 8gb

12、 san 交换机 16口 8gb san 交换机 16口 数据库系统 构成双机 各应用系统 构成群集系 统 备份主服务 器安装备份 软件 容量为14.4tb netstor isum530 8gb光纤盘柜阵列 备份路径 ad域服务器 图 6-1 网路拓扑图 8. 测试策略测试策略 这次性能测试将结合用户在日常工作中的实际操作情况对用户量较大的模块进 行性能测试，选取公众版系统的登陆、服务访问、地图访问、查询功能作为这次性 能测试的对象，并且在此基础上进行组合，设计综合场景进行性能测试。 测试数据准备测试数据准备 为模拟生产环境情况,设定如下基础数据： 模拟用户 500 个 模拟并发用户 50、

13、100、200、300 个 数据库存放 100w 条以上数据量 9. 测试结果及分析测试结果及分析 9.1一般性能测试一般性能测试 场景描述：场景描述：此场景测试 500 个用户访问系统的运行情况。 场景设计：场景设计：每 10 秒加载登录 4 个用户，持续增加在线用户，系统成功加载 500 虚拟用户在线后，所有用户在线持续 5 分钟后，以每 10 秒 5 个用户退出系统。不 考虑 think time。 测试重点：测试重点：页面响应时间，服务器的 cpu、内存使用情况。 测试结果：测试结果： 服务器资源检测如下图： 说明：cpu 利用率最大值 32.552%，小于标准值 80%。磁盘驱动器读

14、写和写入请 求的最小值为 0.096%，值较小表明目前系统真实环境硬件不存在瓶颈。 用户访问点击数如下图： 说明：在加载到 500 个用户的时候，通过集合点使 500 个用户进行事务并发， 能够看出在 500 个用户同时并发时吞吐量呈爬坡式增加，未出现其他异常情况，表 明目前系统在 500 个用户并发处理不存在瓶颈。 结果分析： 分析：在 500 个用户运行的情况下，系统的总吞吐量达到 27,800,954,406 bytes；平均每秒吞吐量 11,497,500 bytes；总点击次数 2,132,992 次；平均每秒 点击次数 882.131 次；vuser end transaction

15、 , vuser init transaction 是系统 默认的事务，actiong transaction 是录制时进行操作的事务，我们可以看到 500 个用户运行事务时，最短的时间为 0.465s，最长时间为 5.125s，平均时间为 3.28s，其中 90%都小于等于 4.243s，500 个用户全部通过。 9.2并发测试并发测试 总体描述：总体描述：500500 个用户成功加载后，分别由个用户成功加载后，分别由 5050、100100、200200、300300 用户做系统并用户做系统并 发测试。发测试。 场景设计：场景设计：每秒加载 5 个用户，持续增加在线用户，系统成功加载 50

16、0 虚拟用 户在线后，设置登录集合点，模拟 50、100、200、300 用户并发登录系统、地图操 作，采取多机联合测试、集合点策略，等待登录用户分别达到 50、100、200、300 个用户时候，同时提交事务，测试 500 人在线后，同时并发 50、100、200、300 个 用户时事务的通过率和响应时间，所有用户加载完后持续运行 3 分钟，以每 10 秒 5 个用户退出系统。不考虑 think time。 测试重点：测试重点：页面响应时间，服务器的 cpu、内存使用情况。 场景一：场景一：500500 个用户成功加载后，其中个用户成功加载后，其中 5050 个用户做并发操作。个用户做并发操

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

18、）cpu 使用率 最小值为 0%、最大值为 8.594%、平均值为 0.930%,符合 cpu 资源利用常规指标 （80%）；available mbytes (memory):物理内存剩余最小值为 712m、最大值 996m、平均值 879.571m，符合物理内存剩余使用量大于 10%的常规指标。 通过分析得出，此系统支持在设定的硬件环境下进行 50 个用户的并发运行。 场景二：场景二：500500 个用户成功加载后，其中个用户成功加载后，其中 100100 个用户做并发操作。个用户做并发操作。 场景描述：场景描述：加载 500 个用户，其中 100 个用户并发操作情况下，对事务响应 时间变

19、化趋势和服务器资源使用情况进行统计分析。 场景设计：场景设计：每 10 秒加载登录 5 个用户，持续增加在线用户，集合点加载到 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

20、 资源利用常规指标 （80%）；available mbytes (memory):物理内存剩余最小值为 883m、最大值 984m、平均值 933.529m，符合物理内存剩余使用量大于 10%的常规指标。 通过分析得出，此系统支持在设定的硬件环境下进行 100 个用户的并发运行。 场景三：场景三：500500 个用户成功加载后，其中个用户成功加载后，其中 200200 个用户做并发操作。个用户做并发操作。 场景描述：场景描述：加载 500 个用户，其中 200 个用户并发操作情况下，对事务响应 时间变化趋势和服务器资源使用情况进行统计分析。 场景设计：场景设计：每 10 秒加载登录 5 个用

21、户，持续增加在线用户，集合点加载到 200 各用户开始进行并发执行事务，系统成功加载 500 虚拟用户在线后，所有用户在线 持续 3 分钟后，以每 10 秒 5 个用户退出系统。不考虑 think time。 根据如上图得到的数据信息：action_transaction 响应时间最大值 4.258s、 最小值 0.187s、平均值 2.956s；processor time（processor_total）：cpu 使用 率最小值为 0%、最大值为 57.552%、平均值为 12.625%，符合 cpu 资源利用常规指 标（80%）；available mbytes (memory):物理内

22、存剩余最小值为 529m、最大值 1027m、平均值 680m，符合物理内存剩余使用量大于 10%的常规指标。 通过分析得出，此系统支持在设定的硬件环境下进行 200 个用户的并发运行。 场景四：场景四：500500 个用户成功加载后，其中个用户成功加载后，其中 300300 个用户做并发操作。个用户做并发操作。 场景描述：场景描述：500 个用户 300 个用户的并发操作情况下，对事务响应时间变化趋 势和服务器资源使用情况进行统计分析。 场景设计：场景设计：每 10 秒加载登录 5 个用户，持续增加在线用户，集合点加载到 300 用户开始进行并发执行事务，系统成功加载 500 虚拟用户在线后

23、，所有用户在线持 续 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 mbytes (memory):物理内存剩余最小值为 658m、最大值 709m、平均值 683.706m，均符合物理内存剩余使用量大于 10

24、%的常规指标。 通过分析得出，此系统支持在设定的硬件环境下进行 300 个用户的并发运行。 结果分析结果分析： 交易响应时间（秒） 并发用户数 最小平均最大 500 用户成功加 载后 50 个用户做并 发登录 0.2032.0036.302 500 用户成功加0.2032.5625.024 载后 100 个用户做 并发登录 500 用户成功加 载后 200 个用户做 并发登录 0.187 2.9564.258 500 用户成功加 载后 300 个用户做 并发登录 0.1873.235.224 1 场景执行情况： 场景执行图中，500 个虚拟用户持续并发进行系统登录、地图浏览过程中，事 务响应时

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

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

27、系统的运行情况。 场景设计：场景设计：每 15 秒加载登录 2 个用户，持续增加在线用户，系统成功加载 100 虚拟用户在线后，所有用户在线持续 20 分钟后，以每 15 秒 2 个用户退出系统。不 考虑 think time。 测试重点：测试重点：页面响应时间，服务器的 cpu、内存使用情况。 测试结果：测试结果： 服务器资源监测图： 事务响应图： 测试结果分析： 平均事物响应时间结果： 测试结论测试结论：页面平均响应时间 0.001s；%processor time 小于 80%，说明 cpu 没有瓶颈； 可用物理内存数 available mbytes 的值很小（4 mb 或更小），则说

28、明计算机上总的内 存可能不足，或某程序没有释放内存。当前监测值为 60829.000，系统不存在内存溢出 的问题。 9.4.2 古建保护与修缮管理古建保护与修缮管理 场景描述：场景描述：此场景测试 100 个用户登录系统的运行情况。 场景设计：场景设计：每 15 秒加载登录 2 个用户，持续增加在线用户，系统成功加载 100 虚拟用户在线后，所有用户在线持续 20 分钟后，以每 15 秒 2 个用户退出系统。不 考虑 think time。 测试重点：测试重点：页面响应时间，服务器的 cpu、内存使用情况。 测试结果：测试结果： 吞吐量监测图： 事务响应时间监测图： 资源监测图： 测试结果分析

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

30、使用情况。 测试结果：测试结果： 资源监测图： 平均事务响应图： 吞吐量监测图： 测试结果分析： 测试结论：测试结论：页面平均响应时间 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。 场景设计图：