性能测试报告案例Word文档格式.docx

1、如不满足，对性能瓶颈进行定位分析，提供性能调优建议。1.2测试时间测试自2008年11月20日启动，至12月01日测试执行结束。1.3测试地点*大厦*座*层1.4测试人员单位备注*公司*北京#公司*2测试方法简介压力测试采用业界成熟的自动化性能测试工具，通过创建压力测试程序、构建压力测试模型，对被测试系统实施自动化压力测试，最后形成压力测试结果分析报告。1）压力测试实施模型：通过自动化测试工具模拟最终用户向服务器发起业务请求，进行性能测试。通过测试工具对测试过程中系统各点进行监控，每一次测试结束后工具自动采集测试结果并生成原始报告供分析使用。2）压力测试实施基本流程：测试环境准备系统性能压力测

2、试环境要求与生产系统的软、硬件环境保持一致，并具有相同规模的业务数据，并保证软件版本与生产环境保持一致。压力模型定义：此次性能测试的用例选择，按照海泰方圆提供的业务数据进行分析抽取，用例选取是性能测试压力模型设计的首要任务。用例选取的原则是：1）典型的交易和业务流程2）用户操作使用频繁3）对系统性能影响较大4）性能测试压力符合业务系统实际的实际交易发生比例实际执行场景的设置尽量模拟实际业务进行，运行时长，操作间隔（思考时间），循环间隔，并发间隔，用户加载和减压时间根据系统基准测试结果进行判断和设置。测试数据准备：测试数据要求尽量模拟真实业务数据，而且具有一定可重用性。能贯穿各相关系统，保证业务

3、流程的顺畅正确。具体的数据类型和数据量需要根据选择的交易类别或性能测试场景设置而定。此外性能测试会产生大量的虚拟用户，需要消耗大量的测试数据。其数量直接关乎测试结果。测试中所需的基本数据类型为：系统用户数据：登陆系统使用的用户名-口令等，数量与虚拟用户数一致。业务数据：每个虚拟用户模拟真实用户进行操作时使用到的数据。辅助数据：为保证业务操作的正常进行而设置的基本信息资料。 测试程序开发：利用在历史数据收集步骤中所获得的典型用户的系统访问模式，做为测试程序开发的依据。该测试程序应该覆盖典型用户的系统访问模式所涉及的操作。脚本的开发是利用LoadRunner Vugen进行脚本录制，开发，参数化，

4、调试的过程。 测试执行：测试准备阶段完毕后，确保测试环境、测试程序、测试过程、测试数据，且均已验证通过后，然后在指定的时间内可对系统施实性能测试，性能测试执行分为两个阶段：1、性能基准测试：系统在轻负载环境下，模拟各业务的单用户交易，评估当前系统的性能表现，并作为后续压力测试的性能比较基准；2、单交易负载测试：3、负载压力测试：仿真现实，模拟大批量并发业务交易，评估系统在高负载情况下系统的性能表现。 测试结果分析报告：压力测试结果经过确认有效后，将汇总压力测试结果，形成最终的性能测试分析报告。3测试环境3.1被测系统3.1.1硬件环境系统IP地址所在主机配置应用服务器192.168.3.13C

5、PU：Xeon MP X4600 2.6GHz内存8G硬盘200G 7200转Win2003 Server数据库服务器192.168.3.15硬盘500G 7200转3.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转负载发生器9192.168.3.130192.168.3.138内存1G/硬盘400G 7200转3.2.2测试软件采用Mercury

6、Interactive公司的LoadRunner测试及分析软件作为测试工具。LoadRunner简介：LoadRunner是一种预测系统行为和性能的工业标准级负载测试工具。在LoadRunner的帮助下，用户可以以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题。LoadRunner 能够对整个企业架构进行测试，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助用户更快的查找和发现问题。此外，LoadRunner 能支持广泛的协议和技术，可以为用户的特殊环境提供特殊的解决方案。本次测试采用的LoadRunner版本为9.0。4测试设计4.1模拟用户数依据系统目前的业务量以及未

7、来业务量增长，对当前系统分别按3000、4500、6000用户进行压力测试，以评估系统在不同压力梯度情况下的性能表现。4.2测试模型建立此次性能测试的业务选择，应覆盖各性能关键业务，并通过海泰方圆、北京行所志双方协商选取被测业务。根据协商选定如下业务进行性能测试：开具发票以此基础上定义测试执行压力模型：在混合业务场景压力梯度测试过程中，分别按3000、4500、6000用户进行压力测试，在各个压力测试过程中保持测试场景和调度测试的完全一致，使结果具有很好的可比性。压力测试执行场景描述如下：1、模拟用户数：3000、4500、60002、Pacing：120秒；3、当所有用户加载完毕后连续运行1

8、5分钟；4、用户调度策略：每1秒启动30个虚拟用户。业务场景一序号交易业务配比执行时间操作间隔100%15分钟120秒业务场景二开具发票（无合同）85%2开具发票（有合同）15%说明：按照以上场景设置，可估算出模拟用户数与每小时业务量的对应关系如下：模拟用户数300045006000每小时业务量900001350001800005测试结果分析术语解释（事务） LoadRunner中定义，为一个流程中某个环节的称谓，一个流程可称为一个大的事务，在这个大的交易中包含许多的小的事务。响应时间 LoadRunner中衡量流程中各个事务性能的最佳手段，计算的是端到端的时间，说的通俗一点，从点击应用中的某

9、个控件，到从数据库返回数据到客户端，整个过程都被计算在事务的响应时间内。场景 LoadRunner中专门术语。它是所有测试资源包括测试脚本、运行设置、运行用户数等的集合。在这个场景中，可以定义并发用户的数目，定义要运行的脚本，或者说运行的流程类型。在一个场景中，可以是单个流程，也可以是多个流程的混合。虚拟用户 LoadRunner中特定术语，为模拟现实中的实际用户，测试软件使用虚拟用户代替真实的用户。5.1业务场景一（无基础数据）梯度压力测试分析5.1.1平均响应时间梯度对比下图是不同用户数下各事务的平均响应时间随用户数变化的曲线：事务3000用户4500用户6000用户登录0.561.312

10、2.14 0.240.872.08 录入并开具0.431.0982.70 平均响应时间分析：从上图中可以看出，各操作的响应时间随着用户数的增加呈上升趋势，但都没有超过5秒，在可接受范围内。5.1.2系统资源利用率CPU利用率分析：在上图中我们可以看出3000用户、4500用户及6000用户时，CPU利用率均在正常范围内，系统表现良好。5.1.3系统处理能力系统处理能力分析：可以看出，在无基础数据的情况下，系统处理能力随用户数的增加呈线性上升趋势，即系统无性能瓶颈，6000用户时系统处理能力达到每小时173880笔，满足并超出客户提出的4小时20万张发票的处理能力。5.2业务场景一对比测试分析用

11、户数基础数据量无126000大于1800万5.2.1平均响应时间对比下图是不同压力情况下，有基础数据与无基础数据各操作响应时间对比图： 同样压力的情况下，在无基础数据的情况下，响应时间均小于5秒。当基础数据量在1800万的时候，6000用户压力下响应时间大幅度提高，超过客户所提出5秒之内的要求。 5.2.2处理能力对比下图是相同压力情况下，有基础数据与无基础数据系统的处理能力对比。处理能力分析： 在有基础数据的情况下，单从处理能力看，依然可以满足客户所提出的要求，但与之前的无基础数据的处理能力比较发现，基础数据的存在是对处理能力有较大影响。5.2.3资源利用率对比图下图是相同压力情况下，有基础

12、数据与无基础数据各事务资源利用率对比图： 相同压力下，因有基础数据情况下响应时间变长，系统处理能力下降，CPU利用率也随之下降，这说明系统瓶颈出现在了其他方面。5.3系统稳定性测试在系统测试过程中，我们发现WebLogic的JVM可用内存逐渐减少， 下图是在WebLogic监控台所监控到的情况：为了验证确认此现象，进行了4500用户6个小时的测试，当测试执行到1小时左右，WebLogic JVM基本已无内存可用，如下图所示：被占用内存无法释放，导致被测系统在长时间运行后响应时间明显上升，处理能力明显下降，如下图所示：分析： 用户在登录时，系统会自动生成一个session，并占用部分内存，而这个

13、session的过期时间设置为2小时，按照用户习惯分析，当用户使用直接关闭IE窗口退出系统的方式退出，这个session是不释放的，并继续占用内存。测试过程中没有做退出操作，导致大量用户session不释放。根据上图显示，40分钟时性能开始下降，此时在线用户数约为37.5*60*40=90000。解决方法：开发人员修改程序，点击重新登录时清除session，并在测试过程中，完成开具发票操作后就点击重新登录。重新执行测试后，此现象消失。5.4有、无合同场景对比测试在测试过程中，用户提出部分用户需要在开具发票是选择合同，因此设计以下场景进行测试。业务配比执行时间5.4.1响应时间分析在4500用户

14、压力下，各操作响应时间如下：业务操作平均响应时间（秒）有合同_登录6.07 有合同_开具发票37.83 有合同_录入并开具6.38 有合同_退出3.85 有合同_选择合同34.96 无合同_登录6.27 无合同_开具发票4.45 无合同_录入并开具6.18 无合同_退出3.84 此时有合同的开具发票、选择合同操作的响应时间已远远超过5秒，其它大部分操作响应时间也超过了5秒。5.4.2处理能力对比图下图是无合同4500用户与有合同4500用户情况下系统处理能力对比图：此时系统处理能力仍然满足4小时20万张发票的要求，但因响应时间过长，认为系统性能不满足要求。5.4.3资源利用率对比图资源利用率分

15、析： 因响应时间过长，出现大量的队列等待，导致CPU利用率下降。5.5业务场景二调优对比测试现象：有合同“开具发票”、“选择合同”操作的响应时间过长。通过数据库监控可以看到，数据库的读操作过于频繁，db file sequential read等待事件占总等待时间的92%以上。经过对系统的监控，分析得出几点对系统性能可能造成影响的原因：1、业务逻辑a）在进入开具发票页面时，系统就加载了全部合同信息，导致“开具发票”操作响应时间过长；b）查询合同信息业务逻辑有问题，导致“选择合同”操作响应时间过长；从数据库监控中看到，以下两个SQL的Disk Reads最大：SELECT * FROM HI_B

16、ARGAIN WHERE SKZZH=:1 AND BG_STATE=正常SELECT IV_AMOUNT FROM 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、调整查询合

17、同信息业务逻辑4、修改weblogic线程数为150调优结果见以下分析。5.5.1第一次调优首先修改业务逻辑，在进入开具发票页面时不加载合同信息。然后修改数据库参数，修改shard pool为104M、修改buffer cache为504M。下图是4500用户调优前后响应时间对比图：事务名称平均响应时间（调优前）平均响应时间（调优后）合同_登录1.2合同_开具发票1.283合同_录入并开具1.378合同_退出0.232合同_选择合同0.483开票_登录1.215开票_开具发票0.568开票_录入并开具1.492开票_退出0.269在图中我们可以看出调优前后，在相同压力的情况下，响应时间大幅度下

18、降。调优效果明显，已满足响应时间小于5秒的业务要求。此时系统处理能力也有明显的提升。5.5.2第二次调优由于此时WebLogic线程经常出现队列，因此将WebLogic线程最大值由100调整为150。调整后系统处理能力由36.004上升为37.394。但由于此时系统处理能力已接近场景设计最大值，因此效果不明显，需要进行一次6000用户的对比测试。6000用户时，响应时间明显变长，部分操作已超过5秒，而系统处理能力也有明显的下降，因此系统仍然存在性能瓶颈。5.5.3第三次调优此时主要的优化方向为优化业务逻辑，因此测试人员提出建议，将查询合同信息的两个SQL合并为一个SQL，这样能够减少大量的查询

19、次数，降低数据库压力。开发人员将此业务逻辑优化后，进行了一次6000用户的对比测试，结果如下：可以看出，调整业务逻辑后，各操作响应时间大幅度缩短，系统处理能力有了明显提升。此时系统处理能力达到每小时164876笔。6测试结论6.1业务场景一（无合同）1、系统在测试硬件、无基础数据的情况下，系统处理能力达到每小时173880笔开发票业务，满足客户所提出的4小时处理20万笔开发票业务，响应时间小于5秒的处理能力。2、系统在测试硬件、有基础数据（1800万条）的情况下，系统处理能力达到每小时122580笔开发票业务，满足客户所提出的4小时处理20万笔开发票，响应时间小于5秒的处理能力。6.2业务场景

20、二（有合同）1、系统调优后，在测试硬件、有基础数据（1800万条）的情况下，系统处理能力达到每小时164876笔开发票业务，满足客户所提出的4小时处理20万笔开发票，响应时间小于5秒的处理能力。6.3稳定性1、在不影响系统处理能力的情况下，目前系统最多能够支持7万用户在线。根据测试估算，约9万用户同时在线时，会导致系统性能急剧下降，详见5.3。7调优建议目前系统处理能力已满足上线后业务高峰期的业务压力，所提建议仅作为系统进一步优化的参考。1、增大WebLogic JVM堆大小，可提高最大在线用户数。当前大小为1000M，最大可设置为1498M。如需进一步提高在线用户数，可部署WebLogic集

21、群。2、当系统压力超过测试最大压力时，增大WebLogic线程池大小，可提升系统处理能力。目前为150，以50为幅度逐步增加。3、数据库服务器4G的内存下，建议：PGA建议从默认的24M调整到200M；SGA建议从默认的138M调整到800M；buffer cache建议从默认的24M调整到500M；Share Pool建议从默认的48M调整到100200M都可以。4、建议将数据库连接池最小连接数设置为20。当数据库连接池可用连接持续为0的情况下，可增大数据数据连接池大小。目前为100，可增至150。5、将所有索引设置为使用INDX表空间，减少资源争抢。6、User表空间目前使用一个数据文件，建议当User表空间超过10G后，使用多个数据文件，每个数据文件大小不超过10G。注：进行以上操作时，应先在测试环境上测试成功后再部署到生产环境上。8北京#软件技术开发有限公司负责人：日期：签字确认