压力检验测试方案计划&压力检验测试报告.doc

《压力检验测试方案计划&ampamp;压力检验测试报告.doc》由会员分享，可在线阅读，更多相关《压力检验测试方案计划&ampamp;压力检验测试报告.doc（34页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、*-压力测试方案&压力测试报告 2009年1月16日(最后更新:2009-02-07) 评论 发表评论 本文共分两部分： 1.压力测试方案2.压力测试报告该报告中使用的技术有loadrunner、nmon和statspack：1）loadrunner主要用来录制测试脚本，设置场景（包括虚拟用户数、操作循环次数、用户载入模式等设置），比较常用，不做单独讲述。2）nmon用来分析OS性能，将在文章“OS性能分析之nmon工具”中讲述。3）statspack用来分析DB性能，将在文章“DB性能分析之statspack工具”中讲述。XXX项目压力测试方案作者 : hand-sail.sun创建日期:

2、2008-12-23最后更新: 2008-12-29控制码 : 版本 : 1.0目录文档控制. 2概述. 4综合压力测试. 5统计负荷指标. 5负荷及指标. 5编制性能指标. 5事务处理响应时间. 5服务器性能信息. 5脚本编写. 6情景设置. 6操作步骤. 6月结压力测试. 8统计负荷指标. 8负荷指标. 8编制性能指标. 8事务处理响应时间. 8服务器性能信息. 9脚本编写. 9情景设置. 9操作步骤. 9测试后期工作. 11概述 在TL-28007测试环境中进行测试，指定特定的负荷指标分别对审计失效、审计启用、TL系统月结请求运行、TL系统月结请求运行和审计同时开启这四种情况进行压力测试

3、，然后对比分析测试结果，验证审计功能对系统性能的影响。压力测试的环境如下：1）TL维护-28007 ORACLE版本信息：11.5.10.2应用层+9.2.0.5.0数据库2）应用服务器信息：10.195.36.11；IBM 9117-570；POWER5 1.94；15G内存；AIX 5.3；3)TL维护-28007 环境SGA信息：Fixed Size 744256 bytesVariable Size 939524096 bytesDatabase Buffers 301989888 bytesRedo Buffers 10760192 bytes综合压力测试 在综合压力测试中将按照测试

4、环境的负荷进行测试，需要从测试结果中得到的有效信息主要是前台响应时间和CPU及磁盘IO等性能指标。综合测试的步骤如下1. 统计负荷指标（前台负荷指标）；2. 定义性能指标，主要包括前台响应时间、CPU及磁盘IO等性能指标；3. 编写压力测试脚本；4. 确定压测负荷，定义压测情景，分别进行四种压力测试；5. 分析对比压力测试的结果，填写压力测试报告。综合压力测试综合压力测试是对销售订单录入操作进行压力测试。需要测试两种情况：1） 审计功能未启用前的测试。2） 审计功能启用后的测试统计负荷指标系统的负荷主要由事务处理组成。其中事务处理主要包括打开销售订单的FORM，增加订单头，增加订单行，保存，登

5、记，审计跟踪信息的保存，关闭销售订单FORM。负荷及指标负荷指标的内容主要包括打开销售订单的FORM，增加订单头，增加订单行，保存，登记，审计跟踪信息的保存这些事务处理的并发用户数量、各种事务处理的数量。编制性能指标性能指标主要是前台事务处理响应时间、服务器性能信息变化情况。事务处理响应时间 对于前台制作订单的过程，需要取到整个过程有关响应时间的指标：最大响应时间最小响应时间平均响应时间响应时间随时间的变化曲线服务器性能信息 分析在前台制作订单整个过程中服务器端相应的性能指标值和变化情况：CPU使用率磁盘I/O情况内存使用情况数据库性能（包括缓冲区中获取Buffer的未等待比率、Redo缓冲区

6、获取Buffer的未等待比率、数据块在数据缓冲区中的命中率、内存中的排序率、sql在共享区的命中率、sql语句解析后被重复执行的次数等。）脚本编写使用loadrunner来制作销售订单过程的脚本，从进入销售订单FORM开始一直到订单登记并关闭订单FORM截止。情景设置各个脚本的并发用户数：Name of Transactionvirtual User Numinterval(s)销售订单录入501、按照上表的虚拟用户数量来设置脚本的虚拟用户数量。2、设置录制订单操作循环10次，也就是一个用户制作10条销售订单。3、设置压力测试的进度表为：同时启动所有的并发用户。在这里需要说明：由于服务器性能因

7、素我们目前只好模拟50个用户测试，因为之前经过多次尝试（审计功能未启用的情况下）发现如果虚拟用户超过100个用户时系统的剩余内存在40-60M上下浮动，无法释放，所有的事务处理也都停止。而用户数在60-100之间时只会成功一部分，结果大多数虚拟用户的处理都是失败的。所以我们以50个用户作为样本，主要分析审计功能启用前后对系统相应性能指标的影响情况。操作步骤1 ) 停止TL28007测试环境所在服务器上的其他应用。2 ) 在TL28007环境中启动nmon 监控系统资源使用情况，启动statpack 监控数据库。3 ) 在loadrunner中，加载设置的场景，按照设定的参数对系统进行压力测试并

8、间隔的运行statpack获取数据库性能信息。4 ) 完成后对loadrunner生成的报表进行分析。5 ) 对nmon和statpack的结果进行分析。6 ) 关闭nmon7 ) 启用审计功能8 ) 在TL28007环境中启动nmon 监控系统资源使用情况，启动statpack 监控数据库。8 ) 在loadrunner中，加载设置的场景，按照设定的参数对系统进行压力测试并间隔的运行statpack获取数据库性能信息。9 ) 完成后对loadrunner生成的报表进行分析。10 )对nmon和statpack的结果进行分析。月结压力测试月结压力测试是对针对月结系统繁忙时，进行销售订单录入操作

9、的压力测试。需要测试两种情况：1） 运行月结时经常启用并且占用大量资源的请求，关闭审计功能，进行录入销售订单操作。2） 运行月结时经常启用并且占用大量资源的请求，启用审计功能，进行录入销售订单操作。统计负荷指标系统的负荷主要由事务处理和后台请求组成。1) 事务处理主要包括：打开销售订单的FORM，增加订单头，增加订单行，保存，登记，审计跟踪信息的保存，关闭销售订单FORM。2) 后台请求主要包括：总帐管理系统传送程序，STD 科目明细帐和STD 汇总试算表报表。负荷指标负荷指标的内容主要包括打开销售订单的FORM，增加订单头，增加订单行，保存，登记，审计跟踪信息的保存这些事务处理的并发用户数量

10、、各种事务处理的数量。另外系统比较大的负荷是后台请求运行以及并发管理器所占用的资源。编制性能指标性能指标主要是前台事务处理响应时间、服务器性能信息变化情况。事务处理响应时间 对于前台制作订单的过程，需要取到整个过程有关响应时间的指标：最大响应时间最小响应时间平均响应时间响应时间随时间的变化曲线服务器性能信息 分析在前台制作订单整个过程中服务器端相应的性能指标值和变化情况：CPU使用率磁盘I/O情况内存使用情况数据库性能（包括缓冲区中获取Buffer的未等待比率、Redo缓冲区获取Buffer的未等待比率、数据块在数据缓冲区中的命中率、内存中的排序率、sql在共享区的命中率、sql语句解析后被重

11、复执行的次数等。）脚本编写使用loadrunner来制作销售订单过程的脚本，从进入销售订单FORM开始一直到订单登记并关闭订单FORM截止。情景设置各个脚本的并发用户数：Name of Transactionvirtual User Numinterval(s)销售订单录入401、按照上表的虚拟用户数量来设置脚本的虚拟用户数量。2、设置录制订单操作循环10次，也就是一个用户制作10条销售订单。3、设置压力测试的进度表为：同时启动所有的并发用户。在这里需要说明：在综合测试中我们使用虚拟用户的数量为50，而在月结压力测试中由于后台请求的繁忙运行和服务器性能的瓶颈，尝试使用50个用户时（审计功能未启

12、用的情况下）结果会产生失败的虚拟用户，为了正确的对比分析审计对系统性能的影响我们使用40个虚拟用户进行测试。操作步骤1 停止TL28007测试环境所在服务器上的其他应用。2 运行总帐管理系统传送程序，STD 科目明细帐和STD 汇总试算表报表这三个请求3 在TL28007环境中启动nmon 监控系统资源使用情况，启动statpack 监控数据库。4 在loadrunner中，加载设置的场景，按照设定的参数对系统进行压力测试并间隔的运行statpack获取数据库性能信息。5 完成后，对loadrunner生成的报表进行分析。6 对nmon和statpack的结果进行分析。7 关闭nmon，关闭请

13、求.8 启用审计功能9 运行总帐管理系统传送程序，STD 科目明细帐和STD 汇总试算表报表这三个请求10 在TL28007环境中启动nmon 监控系统资源使用情况，启动statpack 监控数据库。11 在loadrunner中，加载设置的场景，按照设定的参数对系统进行压力测试并间隔的运行statpack获取数据库性能信息。12 完成后，对loadrunner生成的报表进行分析。13 对nmon和statpack的结果进行分析。测试后期工作测试完成后收集测试数据，分析测试结果，填写测试报告。对比内容：一 综合压力测试1. 前台响应时间2. OS性能指标，包括CPU 、I/O、内存；3. 数据

14、库性能指标，包括缓冲区中获取Buffer的未等待比率、Redo缓冲区获取Buffer的未等待比率、数据块在数据缓冲区中的命中率、内存中的排序率、sql在共享区的命中率、sql语句解析后被重复执行的次数等。二 . 月结压力测试1 前台响应时间2. OS性能指标，包括CPU 、I/O、内存；3. 数据库性能指标，包括缓冲区中获取Buffer的未等待比率、Redo缓冲区获取Buffer的未等待比率、数据块在数据缓冲区中的命中率、内存中的排序率、sql在共享区的命中率、sql语句解析后被重复执行的次数等。分别分析对比审计启用前后的结果，列出在审计功能启用前后的两个测试结果中各项指标的升降情况。根据分析

15、结果，针对审计功能对系统的影响给出评价。XXX项目压力测试报告作者: hand-sail.sun创建日期: 2008-12-23最后更新: 2008-12-29控制码: 版本: 1.0 目录文档控制. 2概述. 4压力测试实施安排. 5综合压力测试. 5环境准备情况. 5前台响应时间对比压力测试. 5后台性能对比压力测试. 6综合压力测试结果数据对比. 6前台响应时间压力测试数据对比分析. 6后台性能压力测试数据对比分析. 8月结压力测试. 15环境准备情况. 15前台响应时间对比压力测试. 15后台性能对比压力测试. 16月结压力测试结果数据对比. 16前台响应时间压力测试数据对比分析. 1

16、6后台性能压力测试数据对比分析. 18对比压力测试结果分析. 25概述本报告是按照“XXX项目压力测试方案v1.0”文档涉及的方案进行测试操作得到的测试结果数据记录，并对比审计功能启用前后来分析结果数据，从而分析审计功能对系统的性能影响情况。由于采用loadrunner作为前台的压力负荷提交工具，是很难实现生产环境使用的多样性和综合性。同时后台的提交也是采用程序提交方式，也必然限定了请求数据的范围。尽管我们选择典型的业务和程序，也不可避免loadrunner的局限性，即无法真实模拟生产环境的应用状况。因此，loadrunner压力测试所带来压力和测试结果数据，只能是在一定程度上模拟。压力测试实

17、施安排为合理组织压力测试实施，我们采用下面的综合压力测试和月结压力测试综合压力测试环境准备情况压力测试环境准备为11.5.10.2测试环境（TL-28007测试），因TL-28007所在服务器上还有一套TL-28009环境，所以测试前先将TL-28009测试环境停止。前台响应时间对比压力测试1） 前台业务操作1.1 打开制作订单页面1.2 输入订单头-输入订单行1.3 保存1.4 登记1.5 关闭订单页面2 ） 并发用户数量及操作间隔时间（50用户）业务名称用户数间隔时间打开制作订单页面500s输入订单头-输入订单行500s保存500s登记500s关闭订单页面500s 我们把每个虚拟用户设置为

18、连续循环10次制作订单，并且所有用户同时载入到系统中（间隔时间0s），这样就足以保证这些用户并发制作销售订单。3 ） 按照同样的策略，在启用审计功能后再进行测试。后台性能对比压力测试1）第一次压力测试（未启用审计功能）期间取得OS和DB的性能数据。2）第二次压力测试（启用审计功能）期间取得OS和DB的性能数据。综合压力测试结果数据对比前台响应时间压力测试数据对比分析本次压力测试主要关注的是审计功能的启用会给系统带来那些性能的问题，而在此处我们所关心的是整个订单录入流程响应时的差别，以下是对比分析订单录入整个流程的响应时间分析图：1） 未启用审计功能前台响应时间绿色-初始化时间蓝色-响应时间2）

19、 启用审计功能前台响应时间绿色-初始化时间蓝色-响应时间对比分析： 从曲线图可以看出，总体响应时间的变化曲线基本一致，审计功能启用后系统处理的时间要稍微长一些，最大的响应时间比审计功能启用前也要长一点，但总体上对系统的影响是很小的。后台性能压力测试数据对比分析后台性能数据包括OS性能和DB性能数据（一） OS性能数据1.1 CPU占有率和磁盘IO1）未启用审计功能前 2） 启用审计功能后对比分析： 从曲线图可以看出，CPU占有率基本一致。在IO方面后者有一个磁盘IO峰值在1400/sec，比前者IO峰值高出150/sec左右，但大部分的IO基本都在1000/sec上下浮动，而前者的IO基本也都

20、是在1000/sec上下浮动，这说明审计功能对IO的影响并不明显。1.2 IO读写情况1）未启用审计功能前2） 启用审计功能后对比分析： 从曲线图可以看出，前后的磁盘读写情况并无明显差别。1.3 内存使用情况1）未启用审计功能前内存剩余情况2） 启用审计功能后内存剩余情况对比分析： 从曲线图可以看出，前后的内存使用情况基本一致，开始阶段两者的内存剩余量都几乎为0，在脚本运行到大概10分钟左右后开始释放内存。（二） DB性能数据1）未启用审计功能前2）启用审计功能后对比分析： 在以上数据中可以看到启用审计功能后DB性能参数和启用审计功能之前DB性能参数并无明显变化。月结压力测试环境准备情况压力测

21、试环境准备为11.5.10.2测试环境（TL-28007测试），因TL-28007所在服务器上还有一套TL-28009环境，所以测试前先将TL-28009测试环境停止。同时在测试之前运行PCSCN_AR职责下的总帐管理系统传送程序、PCSCN_GL职责下的 STD 科目明细帐和STD 汇总试算表报表。前台响应时间对比压力测试1 前台业务操作1.1 打开制作订单页面1.2 输入订单头-输入订单行1.3 保存1.4 登记1.5 关闭订单页面2 并发用户数量及操作间隔时间（40用户）用户数间隔时间打开制作订单页面400s输入订单头-输入订单行400s保存400s登记400s关闭订单页面400s由于把

22、每个虚拟用户设置为连续循环制作10条订单，并且所有用户同时载入到系统中（间隔时间0s），这样就足以保证这些用户并发制作销售订单。由于服务器性能因素加上后台月结相关请求的运行使得系统的压力非常大，所以我们以40个用户来做性能的样本分析。3 按照同样的策略，在启用审计功能后再进行测试。后台性能对比压力测试1）第一次压力测试（未启用审计功能）期间取得OS和DB的性能数据。2）第二次压力测试（启用审计功能）期间取得OS和DB的性能数据。月结压力测试结果数据对比前台响应时间压力测试数据对比分析本次压力测试主要关注的是在月结相关请求运行的情况下审计功能的启用会给系统带来那些性能的问题，而在此处我们所关心的

23、是整个订单录入流程响应时间=时的差别，以下对比分析订单录入流程的响应时间分析图：1） 未启用审计功能前台响应时间绿色-初始化时间蓝色-响应时间2） 启用审计功能前台响应时间绿色-初始化时间蓝色-响应时间对比分析： 从曲线图可以看出，总体响应时间的变化曲线非常相似，说明在月结程序运行的状态下审计对系统性能的影响比率进一步降低了。后台性能压力测试数据对比分析后台性能数据包括OS性能和DB性能数据（一）OS性能数据1.1 CPU占有率和磁盘IO1）未启用审计功能前 2） 启用审计功能后对比分析： 从曲线图可以看出，CPU占有率基本一致。在IO方面后者有一个磁盘IO的峰值在1200/sec，比前者多出

24、200/sec左右，但大部分的IO基本都在1000/sec上下浮动，而前者的IO也都基本接近1000/sec，这说明审计功能对IO的影响并没有太大的波动。1.2 IO读写情况1）未启用审计功能前2） 启用审计功能后对比分析： 从曲线图可以看出，前后的磁盘读写情况并不明显差别。1.3 内存使用情况1）未启用审计功能前内存剩余情况2） 启用审计功能后内存剩余情况对比分析： 从曲线图可以看出，前后的内存使用情况基本一致，开始阶段两者的内存剩余量都几乎为0，在快结束的时候都将内存释放到2000M左右。（二） DB性能数据1）未启用审计功能前2）启用审计功能后对比分析：在以上数据中可以看到所有参数变化并不明显。对比压力测试结果分析经过以上两种压力测试得出了详细的测试结果数据，并对比分析了CPU的使用率、磁盘IO和内存使用情况，也对比了前台的响应时间和DB的性能参数。我们可以看出审计启用前后系统的性能并没有发生明显的变化，其实在审计功能压力测试中我们最关心的是因为审计信息的写磁盘操作而引起磁盘IO过高，从而会影响系统的性能。但通过测试我们发现磁盘IO略有增高，但幅度并不大。另外参考DB性能参数，这些数据在审计功能启用的前后变化并不明显，所以审计功能对系统的整体性能影响并不大。