性能测试报告案例

1、密级：秘密北京*软件技术开发有限公司2008年12月01日*公司*管理系统性能测试分析报告（V2.0）*公司*管理系统性能测试分析报告文档信息标题*公司*管理系统性能测试分析报告创建日期2008-12-01打印日期文件名存放目录所有者作者张三修订记录日期 描述作者对结论进行细化李四文档审核/审批此文档需如下审核。姓名职务/职称签名签名日期公开第 19 页目 录1测试背景11.1测试目标11.2测试时间11.3测试地点11.4测试人员12测试方法简介13测试环境33.1被测系统33.1.1硬件环境33.1.2数据库环境43.1.3软件环境43.2测试系统43.2.1测试环境搭建43.2.2测试软

2、件44测试设计54.1模拟用户数54.2测试模型建立55测试结果分析65.1业务场景一（无基础数据）梯度压力测试分析65.1.1平均响应时间梯度对比65.1.2系统资源利用率75.1.3系统处理能力85.2业务场景一对比测试分析85.2.1平均响应时间对比85.2.2处理能力对比95.2.3资源利用率对比图95.3系统稳定性测试105.4有、无合同场景对比测试115.4.1响应时间分析115.4.2处理能力对比图125.4.3资源利用率对比图135.5业务场景二调优对比测试135.5.1第一次调优145.5.2第二次调优155.5.3第三次调优166测试结论176.1业务场景一（无合同）176

3、.2业务场景二（有合同）176.3稳定性187调优建议188签字确认191 测试背景1.1 测试目标对*公司*管理系统的开具发票功能进行性能测试，客观、公正评估系统的性能现状。1、开发正确、有效的性能测试脚本，模拟企业用户开具发票操作行为，作为测试有效实施的基础；2、通过性能测试，客观、公正评估在当前测试环境下，被测系统的各项性能指标表现；3、验证被测系统的业务处理能力是否能够满足在业务高峰期的性能要求，为被测系统上线提供参考依据。如不满足，对性能瓶颈进行定位分析，提供性能调优建议。1.2 测试时间测试自2008年11月20日启动，至12月01日测试执行结束。1.3 测试地点*大厦*座*层1.

4、4 测试人员单位姓名备注*公司*北京#公司*2 测试方法简介压力测试采用业界成熟的自动化性能测试工具，通过创建压力测试程序、构建压力测试模型，对被测试系统实施自动化压力测试，最后形成压力测试结果分析报告。1）压力测试实施模型：通过自动化测试工具模拟最终用户向服务器发起业务请求，进行性能测试。通过测试工具对测试过程中系统各点进行监控，每一次测试结束后工具自动采集测试结果并生成原始报告供分析使用。2）压力测试实施基本流程：l 测试环境准备系统性能压力测试环境要求与生产系统的软、硬件环境保持一致，并具有相同规模的业务数据，并保证软件版本与生产环境保持一致。l 压力模型定义：此次性能测试的用例选择，按

5、照海泰方圆提供的业务数据进行分析抽取，用例选取是性能测试压力模型设计的首要任务。用例选取的原则是：1) 典型的交易和业务流程2) 用户操作使用频繁3) 对系统性能影响较大4) 性能测试压力符合业务系统实际的实际交易发生比例实际执行场景的设置尽量模拟实际业务进行，运行时长，操作间隔（思考时间），循环间隔，并发间隔，用户加载和减压时间根据系统基准测试结果进行判断和设置。l 测试数据准备：测试数据要求尽量模拟真实业务数据，而且具有一定可重用性。能贯穿各相关系统，保证业务流程的顺畅正确。具体的数据类型和数据量需要根据选择的交易类别或性能测试场景设置而定。此外性能测试会产生大量的虚拟用户，需要消耗大量的

6、测试数据。其数量直接关乎测试结果。测试中所需的基本数据类型为：u 系统用户数据：登陆系统使用的用户名-口令等，数量与虚拟用户数一致。u 业务数据：每个虚拟用户模拟真实用户进行操作时使用到的数据。u 辅助数据：为保证业务操作的正常进行而设置的基本信息资料。l 测试程序开发：利用在历史数据收集步骤中所获得的典型用户的系统访问模式，做为测试程序开发的依据。该测试程序应该覆盖典型用户的系统访问模式所涉及的操作。脚本的开发是利用LoadRunner Vugen进行脚本录制，开发，参数化，调试的过程。l 测试执行：测试准备阶段完毕后，确保测试环境、测试程序、测试过程、测试数据，且均已验证通过后，然后在指定

7、的时间内可对系统施实性能测试，性能测试执行分为两个阶段：1、 性能基准测试：系统在轻负载环境下，模拟各业务的单用户交易，评估当前系统的性能表现，并作为后续压力测试的性能比较基准；2、 单交易负载测试：3、 负载压力测试：仿真现实，模拟大批量并发业务交易，评估系统在高负载情况下系统的性能表现。l 测试结果分析报告：压力测试结果经过确认有效后，将汇总压力测试结果，形成最终的性能测试分析报告。3 测试环境3.1 被测系统3.1.1 硬件环境系统IP地址所在主机配置备注应用服务器192.168.3.13CPU：Xeon MP X4600 2.6GHz内存8G硬盘200G 7200转Win2003 Se

8、rver数据库服务器192.168.3.15CPU：Xeon MP X4600 2.6GHz内存8G硬盘500G 7200转Win2003 Server3.1.2 数据库环境使用生成的6800万条数据。3.1.3 软件环境类型应用及版本号备注应用服务器Weblogic8.1数据库Oracle 9i3.2 测试系统3.2.1 测试环境搭建测试机配置：类型数量（台）IP配置备注控制台1192.168.3.129Intel E4600 2.4GHz内存2G/硬盘400G 7200转Win2003 Server负载发生器9192.168.3.130192.168.3.138Intel E4600 2.

9、4GHz内存1G/硬盘400G 7200转Win2003 Server3.2.2 测试软件采用Mercury Interactive公司的LoadRunner测试及分析软件作为测试工具。LoadRunner简介：LoadRunner是一种预测系统行为和性能的工业标准级负载测试工具。在LoadRunner的帮助下，用户可以以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题。LoadRunner 能够对整个企业架构进行测试，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助用户更快的查找和发现问题。此外，LoadRunner 能支持广泛的协议和技术，可以为用户的特殊环境提供特殊的

10、解决方案。本次测试采用的LoadRunner版本为9.0。4 测试设计4.1 模拟用户数依据系统目前的业务量以及未来业务量增长，对当前系统分别按3000、4500、6000用户进行压力测试，以评估系统在不同压力梯度情况下的性能表现。4.2 测试模型建立此次性能测试的业务选择，应覆盖各性能关键业务，并通过海泰方圆、北京行所志双方协商选取被测业务。根据协商选定如下业务进行性能测试：Ø 开具发票以此基础上定义测试执行压力模型：在混合业务场景压力梯度测试过程中，分别按3000、4500、6000用户进行压力测试，在各个压力测试过程中保持测试场景和调度测试的完全一致，使结果具有很好的可比性。压

11、力测试执行场景描述如下：1、 模拟用户数：3000、4500、60002、 Pacing：120秒；3、 当所有用户加载完毕后连续运行15分钟；4、 用户调度策略：每1秒启动30个虚拟用户。业务场景一序号交易业务配比执行时间操作间隔1开具发票100%15分钟120秒业务场景二序号交易业务配比执行时间操作间隔1开具发票（无合同）85%15分钟120秒2开具发票（有合同）15%说明：按照以上场景设置，可估算出模拟用户数与每小时业务量的对应关系如下：模拟用户数300045006000每小时业务量900001350001800005 测试结果分析说明：术语解释² （事务） LoadRunne

12、r中定义，为一个流程中某个环节的称谓，一个流程可称为一个大的事务，在这个大的交易中包含许多的小的事务。² 响应时间 LoadRunner中衡量流程中各个事务性能的最佳手段，计算的是端到端的时间，说的通俗一点，从点击应用中的某个控件，到从数据库返回数据到客户端，整个过程都被计算在事务的响应时间内。² 场景 LoadRunner中专门术语。它是所有测试资源包括测试脚本、运行设置、运行用户数等的集合。在这个场景中，可以定义并发用户的数目，定义要运行的脚本，或者说运行的流程类型。在一个场景中，可以是单个流程，也可以是多个流程的混合。² 虚拟用户 LoadRunner中特定

13、术语，为模拟现实中的实际用户，测试软件使用虚拟用户代替真实的用户。5.1 业务场景一（无基础数据）梯度压力测试分析5.1.1 平均响应时间梯度对比下图是不同用户数下各事务的平均响应时间随用户数变化的曲线：事务3000用户4500用户6000用户登录0.561.3122.14 开具发票0.240.872.08 录入并开具0.431.0982.70 平均响应时间分析：从上图中可以看出，各操作的响应时间随着用户数的增加呈上升趋势，但都没有超过5秒，在可接受范围内。5.1.2 系统资源利用率CPU利用率分析：在上图中我们可以看出3000用户、4500用户及6000用户时，CPU利用率均在正常范围内，系

14、统表现良好。5.1.3 系统处理能力系统处理能力分析：可以看出，在无基础数据的情况下，系统处理能力随用户数的增加呈线性上升趋势，即系统无性能瓶颈，6000用户时系统处理能力达到每小时173880笔，满足并超出客户提出的4小时20万张发票的处理能力。5.2 业务场景一对比测试分析序号用户数每小时业务量基础数据量16000180000无26000126000大于1800万5.2.1 平均响应时间对比下图是不同压力情况下，有基础数据与无基础数据各操作响应时间对比图：平均响应时间分析：同样压力的情况下，在无基础数据的情况下，响应时间均小于5秒。当基础数据量在1800万的时候，6000用户压力下响应时间

15、大幅度提高，超过客户所提出5秒之内的要求。 5.2.2 处理能力对比下图是相同压力情况下，有基础数据与无基础数据系统的处理能力对比。处理能力分析：在有基础数据的情况下，单从处理能力看，依然可以满足客户所提出的要求，但与之前的无基础数据的处理能力比较发现，基础数据的存在是对处理能力有较大影响。 5.2.3 资源利用率对比图下图是相同压力情况下，有基础数据与无基础数据各事务资源利用率对比图：CPU利用率分析：相同压力下，因有基础数据情况下响应时间变长，系统处理能力下降，CPU利用率也随之下降，这说明系统瓶颈出现在了其他方面。5.3 系统稳定性测试在系统测试过程中，我们发现WebLogic的JVM可

16、用内存逐渐减少， 下图是在WebLogic监控台所监控到的情况：为了验证确认此现象，进行了4500用户6个小时的测试，当测试执行到1小时左右，WebLogic JVM基本已无内存可用，如下图所示：被占用内存无法释放，导致被测系统在长时间运行后响应时间明显上升，处理能力明显下降，如下图所示：分析： 用户在登录时，系统会自动生成一个session，并占用部分内存，而这个session的过期时间设置为2小时，按照用户习惯分析，当用户使用直接关闭IE窗口退出系统的方式退出，这个session是不释放的，并继续占用内存。测试过程中没有做退出操作，导致大量用户session不释放。根据上图显示，40分钟时

17、性能开始下降，此时在线用户数约为37.5*60*40=90000。解决方法：开发人员修改程序，点击重新登录时清除session，并在测试过程中，完成开具发票操作后就点击重新登录。重新执行测试后，此现象消失。5.4 有、无合同场景对比测试在测试过程中，用户提出部分用户需要在开具发票是选择合同，因此设计以下场景进行测试。序号交易业务配比执行时间1开具发票（无合同）85%15分钟2开具发票（有合同）15%5.4.1 响应时间分析在4500用户压力下，各操作响应时间如下：业务操作平均响应时间（秒）有合同_登录6.07 有合同_开具发票37.83 有合同_录入并开具6.38 有合同_退出3.85 有合同

18、_选择合同34.96 无合同_登录6.27 无合同_开具发票4.45 无合同_录入并开具6.18 无合同_退出3.84 说明：此时有合同的开具发票、选择合同操作的响应时间已远远超过5秒，其它大部分操作响应时间也超过了5秒。5.4.2 处理能力对比图下图是无合同4500用户与有合同4500用户情况下系统处理能力对比图：分析：此时系统处理能力仍然满足4小时20万张发票的要求，但因响应时间过长，认为系统性能不满足要求。5.4.3 资源利用率对比图资源利用率分析：因响应时间过长，出现大量的队列等待，导致CPU利用率下降。5.5 业务场景二调优对比测试现象：有合同“开具发票”、“选择合同”操作的响应时间

19、过长。通过数据库监控可以看到，数据库的读操作过于频繁，db file sequential read等待事件占总等待时间的92%以上。分析：经过对系统的监控，分析得出几点对系统性能可能造成影响的原因：1、 业务逻辑a) 在进入开具发票页面时，系统就加载了全部合同信息，导致“开具发票”操作响应时间过长；b) 查询合同信息业务逻辑有问题，导致“选择合同”操作响应时间过长；从数据库监控中看到，以下两个SQL的Disk Reads最大：SELECT * FROM HI_BARGAIN WHERE SKZZH=:1 AND BG_STATE='正常'SELECT IV_AMOUNT FR

20、OM HI_INVOICE WHERE BG_CODE=:1 AND (IV_STATE='正常' or IV_STATE='冲红') AND IV_STATE_2='正常'经开发人员确认，这两个SQL是查询合同信息使用的SQL。2、 系统参数a) WebLogic线程数设置过小；b) Oracle的shared pool、buffer cache设置过小。我们对各原因分别进行优化后进行测试，最终进行了以下调整：1、 调整shard pool为104MB2、 调整buffer cache为504MB3、 调整查询合同信息业务逻辑4、 修改webl

21、ogic线程数为150调优结果见以下分析。5.5.1 第一次调优首先修改业务逻辑，在进入开具发票页面时不加载合同信息。然后修改数据库参数，修改shard pool为104M、修改buffer cache为504M。下图是4500用户调优前后响应时间对比图：事务名称平均响应时间（调优前）平均响应时间（调优后）合同_登录6.07 1.2合同_开具发票37.83 1.283合同_录入并开具6.38 1.378合同_退出3.85 0.232合同_选择合同34.96 0.483开票_登录6.27 1.215开票_开具发票4.45 0.568开票_录入并开具6.18 1.492开票_退出3.84 0.26

22、9在图中我们可以看出调优前后，在相同压力的情况下，响应时间大幅度下降。调优效果明显，已满足响应时间小于5秒的业务要求。此时系统处理能力也有明显的提升。5.5.2 第二次调优由于此时WebLogic线程经常出现队列，因此将WebLogic线程最大值由100调整为150。调整后系统处理能力由36.004上升为37.394。但由于此时系统处理能力已接近场景设计最大值，因此效果不明显，需要进行一次6000用户的对比测试。6000用户时，响应时间明显变长，部分操作已超过5秒，而系统处理能力也有明显的下降，因此系统仍然存在性能瓶颈。5.5.3 第三次调优此时主要的优化方向为优化业务逻辑，因此测试人员提出建议，将查询合同信息的两个SQL合并为一个SQL，这样能够减少大量的查询次数，降低数据库压力。开发人员将此业务逻辑优化后，进行了一次6000用户的对比测试，结果如下：可以看出，调整业务逻辑后，各操作响应时间大幅度缩短，系统处理能力有了明显提升。此时系统处理能力达到每小时164876笔。6 测试结论6.1 业务场景一（无合同）1、 系统在测试硬件、无基础数据的情况下，系统处理能力达到每小时173880笔开发票业务，满足客户所提出的4小时处理20万笔开发票业务，响应时间小于5秒的处理能力。2、 系统在测试硬件、有基础数据（1800万条）的情况下，系统处理能力达到每小时122580笔开发票