压力测试方案&压力测试报告.doc

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

2、项目压力测试方案作者 : hand-sail.sun创建日期: 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

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

5、负荷主要由事务处理组成。其中事务处理主要包括打开销售订单的 FORM，增加订单头，增加订单行，保存，登记，审计跟踪信息的保存，关闭销售订单 FORM。负 荷 及 指 标负荷指标的内容主要包括打开销售订单的 FORM，增加订单头，增加订单行，保存，登记，审计跟踪信息的保存这些事务处理的并发用户数量、各种事务处理的数量。编 制 性 能 指 标性能指标主要是前台事务处理响应时间、服务器性能信息变化情况。事 务 处 理 响 应 时 间对于前台制作订单的过程，需要取到整个过程有关响应时间的指标：最大响应时间最小响应时间平均响应时间响应时间随时间的变化曲线服 务 器 性 能 信 息分析在前台制作订单整个过

6、程中服务器端相应的性能指标值和变化情况：CPU 使用率磁盘 I/O 情况内存使用情况数据库性能（包括缓冲区中获取 Buffer 的未等待比率、Redo 缓冲区获取 Buffer 的未等待比率、数据块在数据缓冲区中的命中率、内存中的排序率、sql 在共享区的命中率、sql 语句解析后被重复执行的次数等。）脚 本 编 写使用 loadrunner 来制作销售订单过程的脚本，从进入销售订单 FORM 开始一直到订单登记并关闭订单FORM 截止。情 景 设 置各个脚本的并发用户数：Name of Transactionvirtual User Num interval(s)销售订单录入 50 1、按照

7、上表的虚拟用户数量来设置脚本的虚拟用户数量。2、设置录制订单操作循环 10 次，也就是一个用户制作 10 条销售订单。3、设置压力测试的进度表为：同时启动所有的并发用户。在这里需要说明：由于服务器性能因素我们目前只好模拟 50 个用户测试，因为之前经过多次尝试（审计功能未启用的情况下）发现如果虚拟用户超过 100 个用户时系统的剩余内存在 40-60M 上下浮动，无法释放，所有的事务处理也都停止。而用户数在 60-100 之间时只会成功一部分，结果大多数虚拟用户的处理都是失败的。所以我们以 50 个用户作为样本，主要分析审计功能启用前后对系统相应性能指标的影响情况。操 作 步 骤1 ) 停止

8、TL28007 测试环境所在服务器上的其他应用。2 ) 在 TL28007 环境中启动 nmon 监控系统资源使用情况，启动 statpack 监控数据库。3 ) 在 loadrunner 中，加载设置的场景，按照设定的参数对系统进行压力测试并间隔的运行 statpack获取数据库性能信息。4 ) 完成后对 loadrunner 生成的报表进行分析。5 ) 对 nmon 和 statpack 的结果进行分析。6 ) 关闭 nmon7 ) 启用审计功能8 ) 在 TL28007 环境中启动 nmon 监控系统资源使用情况，启动 statpack 监控数据库。8 ) 在 loadrunner 中，

9、加载设置的场景，按照设定的参数对系统进行压力测试并间隔的运行 statpack获取数据库性能信息。9 ) 完成后对 loadrunner 生成的报表进行分析。10 )对 nmon 和 statpack 的结果进行分析。月 结 压 力 测 试月结压力测试是对针对月结系统繁忙时，进行销售订单录入操作的压力测试。需要测试两种情况：1） 运行月结时经常启用并且占用大量资源的请求，关闭审计功能，进行录入销售订单操作。2） 运行月结时经常启用并且占用大量资源的请求，启用审计功能，进行录入销售订单操作。统 计 负 荷 指 标系统的负荷主要由事务处理和后台请求组成。1) 事务处理主要包括：打开销售订单的 FO

10、RM，增加订单头，增加订单行，保存，登记，审计跟踪信息的保存，关闭销售订单 FORM。2) 后台请求主要包括：总帐管理系统传送程序，STD 科目明细帐和 STD 汇总试算表报表。负 荷 指 标负荷指标的内容主要包括打开销售订单的 FORM，增加订单头，增加订单行，保存，登记，审计跟踪信息的保存这些事务处理的并发用户数量、各种事务处理的数量。另外系统比较大的负荷是后台请求运行以及并发管理器所占用的资源。编 制 性 能 指 标性能指标主要是前台事务处理响应时间、服务器性能信息变化情况。事 务 处 理 响 应 时 间对于前台制作订单的过程，需要取到整个过程有关响应时间的指标：最大响应时间最小响应时间

11、平均响应时间响应时间随时间的变化曲线服 务 器 性 能 信 息分析在前台制作订单整个过程中服务器端相应的性能指标值和变化情况：CPU 使用率磁盘 I/O 情况内存使用情况数据库性能（包括缓冲区中获取 Buffer 的未等待比率、Redo 缓冲区获取 Buffer 的未等待比率、数据块在数据缓冲区中的命中率、内存中的排序率、sql 在共享区的命中率、sql 语句解析后被重复执行的次数等。）脚 本 编 写使用 loadrunner 来制作销售订单过程的脚本，从进入销售订单 FORM 开始一直到订单登记并关闭订单FORM 截止。情 景 设 置各个脚本的并发用户数：Name of Transactio

12、nvirtual User Num interval(s)销售订单录入 40 1、按照上表的虚拟用户数量来设置脚本的虚拟用户数量。2、设置录制订单操作循环 10 次，也就是一个用户制作 10 条销售订单。3、设置压力测试的进度表为：同时启动所有的并发用户。在这里需要说明：在综合测试中我们使用虚拟用户的数量为 50，而在月结压力测试中由于后台请求的繁忙运行和服务器性能的瓶颈，尝试使用 50 个用户时（审计功能未启用的情况下）结果会产生失败的虚拟用户，为了正确的对比分析审计对系统性能的影响我们使用 40 个虚拟用户进行测试。操 作 步 骤1 停止 TL28007 测试环境所在服务器上的其他应用。2

13、 运行总帐管理系统传送程序，STD 科目明细帐和 STD 汇总试算表报表这三个请求3 在 TL28007 环境中启动 nmon 监控系统资源使用情况，启动 statpack 监控数据库。4 在 loadrunner 中，加载设置的场景，按照设定的参数对系统进行压力测试并间隔的运行 statpack 获取数据库性能信息。5 完成后，对 loadrunner 生成的报表进行分析。6 对 nmon 和 statpack 的结果进行分析。7 关闭 nmon，关闭请求 .8 启用审计功能9 运行总帐管理系统传送程序，STD 科目明细帐和 STD 汇总试算表报表这三个请求10 在 TL28007 环境中启

14、动 nmon 监控系统资源使用情况，启动 statpack 监控数据库。11 在 loadrunner 中，加载设置的场景，按照设定的参数对系统进行压力测试并间隔的运行 statpack获取数据库性能信息。12 完成后，对 loadrunner 生成的报表进行分析。13 对 nmon 和 statpack 的结果进行分析。测 试 后 期 工 作测试完成后收集测试数据，分析测试结果，填写测试报告。对比内容：一 综合压力测试1. 前台响应时间2. OS 性能指标，包括 CPU 、I/O、内存；3. 数据库性能指标，包括缓冲区中获取 Buffer 的未等待比率、Redo 缓冲区获取 Buffer 的

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

16、 作者: 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前台响应时间压力测试数据对比分析. 16后台性能压力测试数据对比分析 18对比压力测试结果分析 25概 述本报告是按照

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

18、试和月结压力测试综 合 压 力 测 试环 境 准 备 情 况压力测试环境准备为 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 用户）我们把每个虚拟用户设置为连续循环 10 次制作订单，并且所有用户同时载入到系统中（间隔时间 0s），这样就足以保证这些用户并发制作销售订单

19、。业务名称 用户数 间隔时间打开制作订单页面 50 0s输入订单头-输入订单行 50 0s保存 50 0s登记 50 0s关闭订单页面 50 0s3 ） 按照同样的策略，在启用审计功能后再进行测试。后 台 性 能 对 比 压 力 测 试1）第一次压力测试（未启用审计功能）期间取得 OS 和 DB 的性能数据。2）第二次压力测试（启用审计功能）期间取得 OS 和 DB 的性能数据。综 合 压 力 测 试 结 果 数 据 对 比前 台 响 应 时 间 压 力 测 试 数 据 对 比 分 析本次压力测试主要关注的是审计功能的启用会给系统带来那些性能的问题，而在此处我们所关心的是整个订单录入流程响应时

20、的差别，以下是对比分析订单录入整个流程的响应时间分析图：1） 未启用审计功能前台响应时间绿色-初始化时间蓝色-响应时间2） 启用审计功能前台响应时间绿色-初始化时间蓝色-响应时间对比分析： 从曲线图可以看出，总体响应时间的变化曲线基本一致，审计功能启用后系统处理的时间要稍微长一些，最大的响应时间比审计功能启用前也要长一点，但总体上对系统的影响是很小的。后 台 性 能 压 力 测 试 数 据 对 比 分 析后台性能数据包括 OS 性能和 DB 性能数据（一） OS 性能数据1.1 CPU 占有率和磁盘 IO1）未启用审计功能前2） 启用审计功能后对比分析： 从曲线图可以看出，CPU 占有率基本一

21、致。在 IO 方面后者有一个磁盘 IO 峰值在 1400/sec，比前者 IO峰值高出 150/sec 左右，但大部分的 IO 基本都在 1000/sec 上下浮动，而前者的 IO 基本也都是在1000/sec 上下浮动，这说明审计功能对 IO 的影响并不明显。1.2 IO 读写情况1）未启用审计功能前2） 启用审计功能后对比分析： 从曲线图可以看出，前后的磁盘读写情况并无明显差别。1.3 内存使用情况1）未启用审计功能前内存剩余情况2） 启用审计功能后内存剩余情况对比分析： 从曲线图可以看出，前后的内存使用情况基本一致，开始阶段两者的内存剩余量都几乎为 0，在脚本运行到大概 10 分钟左右后

22、开始释放内存。（二） DB 性能数据1）未启用审计功能前2）启用审计功能后对比分析： 在以上数据中可以看到启用审计功能后 DB 性能参数和启用审计功能之前 DB 性能参数并无明显变化。月 结 压 力 测 试环 境 准 备 情 况压力测试环境准备为 11.5.10.2 测试环境（TL-28007 测试），因 TL-28007 所在服务器上还有一套TL-28009 环境，所以测试前先将 TL-28009 测试环境停止。同时在测试之前运行 PCSCN_AR 职责下的总帐管理系统传送程序、PCSCN_GL 职责下的 STD 科目明细帐和 STD 汇总试算表报表。前 台 响 应 时 间 对 比 压 力

23、测 试1 前台业务操作1.1 打开制作订单页面1.2 输入订单头 -输入订单行1.3 保存1.4 登记1.5 关闭订单页面2 并发用户数量及操作间隔时间（40 用户）由于把每个虚拟用户设置为连续循环制作 10 条订单，并且所有用户同时载入到系统中（间隔时间 0s），这样就足以保证这些用户并发制作销售订单。由于服务器性能因素加上后台月结相关请求的运行使得系统的压力非常大，所以我们以 40 个用户来做性能的样本分析。3 按照同样的策略，在启用审计功能后再进行测试。用户数 间隔时间打开制作订单页面 40 0s输入订单头-输入订单行 40 0s保存 40 0s登记 40 0s关闭订单页面 40 0s后

24、 台 性 能 对 比 压 力 测 试1）第一次压力测试（未启用审计功能）期间取得 OS 和 DB 的性能数据。2）第二次压力测试（启用审计功能）期间取得 OS 和 DB 的性能数据。月 结 压 力 测 试 结 果 数 据 对 比前 台 响 应 时 间 压 力 测 试 数 据 对 比 分 析本次压力测试主要关注的是在月结相关请求运行的情况下审计功能的启用会给系统带来那些性能的问题，而在此处我们所关心的是整个订单录入流程响应时间=时的差别，以下对比分析订单录入流程的响应时间分析图：1） 未启用审计功能前台响应时间绿色-初始化时间蓝色-响应时间2） 启用审计功能前台响应时间绿色-初始化时间蓝色-响应

25、时间对比分析： 从曲线图可以看出，总体响应时间的变化曲线非常相似，说明在月结程序运行的状态下审计对系统性能的影响比率进一步降低了。后 台 性 能 压 力 测 试 数 据 对 比 分 析后台性能数据包括 OS 性能和 DB 性能数据（一）OS 性能数据1.1 CPU 占有率和磁盘 IO1）未启用审计功能前2） 启用审计功能后对比分析： 从曲线图可以看出，CPU 占有率基本一致。在 IO 方面后者有一个磁盘 IO 的峰值在 1200/sec，比前者多出 200/sec 左右，但大部分的 IO 基本都在 1000/sec 上下浮动，而前者的 IO 也都基本接近1000/sec，这说明审计功能对 IO 的影响并没有太大的波动。1.2 IO 读写情况1）未启用审计功能前2） 启用审计功能后