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

压力测试&压力测试报告 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 创建日期:        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系统月结请求运行和审计同时开启这四种情况进行压力测试，然后对比分析测试结果，验证审计功能对系统性能的影响。 压力测试的环境如下： 1）TL维护-28007  ORACLE版本信息： 11.5.10.2应用层+9.2.0.5.0数据库 2）应用服务器信息： 10.195.36.11；IBM 9117-570；POWER5  1.9×4；15G内存；AIX 5.3； 3)   TL维护-28007  环境SGA信息： Fixed Size 744256 bytes Variable Size 939524096 bytes Database Buffers 301989888 bytes Redo Buffers 10760192 bytes   综合压力测试 在综合压力测试中将按照测试环境的负荷进行测试，需要从测试结果中得到的有效信息主要是前台响应时间和CPU及磁盘IO等性能指标。综合测试的步骤如下 1.         统计负荷指标（前台负荷指标）； 2.         定义性能指标，主要包括前台响应时间、CPU及磁盘IO等性能指标； 3.         编写压力测试脚本； 4.         确定压测负荷，定义压测情景，分别进行四种压力测试； 5.         分析对比压力测试的结果，填写压力测试报告。 综合压力测试 综合压力测试是对销售订单录入操作进行压力测试。 需要测试两种情况： 1）  审计功能未启用前的测试。 2）  审计功能启用后的测试 统计负荷指标 系统的负荷主要由事务处理组成。其中事务处理主要包括打开销售订单的FORM，增加订单头，增加订单行，保存，登记，审计跟踪信息的保存，关闭销售订单FORM。 负荷及指标 负荷指标的内容主要包括打开销售订单的FORM，增加订单头，增加订单行，保存，登记，审计跟踪信息的保存这些事务处理的并发用户数量、各种事务处理的数量。 编制性能指标 性能指标主要是前台事务处理响应时间、服务器性能信息变化情况。 事务处理响应时间 对于前台制作订单的过程，需要取到整个过程有关响应时间的指标： 最大响应时间 最小响应时间 平均响应时间 响应时间随时间的变化曲线 服务器性能信息 分析在前台制作订单整个过程中服务器端相应的性能指标值和变化情况： CPU使用率 磁盘I/O情况 内存使用情况 数据库性能（包括缓冲区中获取Buffer的未等待比率、Redo缓冲区获取Buffer的未等待比率、数据块在数据缓冲区中的命中率、内存中的排序率、sql在共享区的命中率、sql语句解析后被重复执行的次数等。） 脚本编写 使用loadrunner来制作销售订单过程的脚本，从进入销售订单FORM开始一直到订单登记并关闭订单FORM截止。 情景设置 各个脚本的并发用户数： Name of Transaction virtual User Num interval(s) 销售订单录入 50       1、按照上表的虚拟用户数量来设置脚本的虚拟用户数量。 2、设置录制订单操作循环10次，也就是一个用户制作10条销售订单。 3、设置压力测试的进度表为：同时启动所有的并发用户。 在这里需要说明：由于服务器性能因素我们目前只好模拟50个用户测试，因为之前经过多次尝试（审计功能未启用的情况下）发现如果虚拟用户超过100个用户时系统的剩余内存在40-60M上下浮动，无法释放，所有的事务处理也都停止。而用户数在60-100之间时只会成功一部分，结果大多数虚拟用户的处理都是失败的。所以我们以50个用户作为样本，主要分析审计功能启用前后对系统相应性能指标的影响情况。 操作步骤 1 ) 停止TL28007测试环境所在服务器上的其他应用。 2 ) 在TL28007环境中启动nmon 监控系统资源使用情况，启动statpack 监控数据库。 3 ) 在loadrunner中，加载设置的场景，按照设定的参数对系统进行压力测试并间隔的运行statpack获取数据库性能信息。 4 ) 完成后对loadrunner生成的报表进行分析。 5 ) 对nmon和statpack的结果进行分析。 6 ) 关闭nmon 7 ) 启用审计功能 8 ) 在TL28007环境中启动nmon 监控系统资源使用情况，启动statpack 监控数据库。 8 ) 在loadrunner中，加载设置的场景，按照设定的参数对系统进行压力测试并间隔的运行statpack获取数据库性能信息。 9 ) 完成后对loadrunner生成的报表进行分析。 10 )对nmon和statpack的结果进行分析。 月结压力测试 月结压力测试是对针对月结系统繁忙时，进行销售订单录入操作的压力测试。 需要测试两种情况： 1）  运行月结时经常启用并且占用大量资源的请求，关闭审计功能，进行录入销售订单操作。 2）  运行月结时经常启用并且占用大量资源的请求，启用审计功能，进行录入销售订单操作。 统计负荷指标 系统的负荷主要由事务处理和后台请求组成。 1) 事务处理主要包括：打开销售订单的FORM，增加订单头，增加订单行，保存，登记，审计跟踪信息的保存，关闭销售订单FORM。 2) 后台请求主要包括：总帐管理系统传送程序，STD 科目明细帐和STD 汇总试算表报表。 负荷指标 负荷指标的内容主要包括打开销售订单的FORM，增加订单头，增加订单行，保存，登记，审计跟踪信息的保存这些事务处理的并发用户数量、各种事务处理的数量。另外系统比较大的负荷是后台请求运行以及并发管理器所占用的资源。 编制性能指标 性能指标主要是前台事务处理响应时间、服务器性能信息变化情况。 事务处理响应时间 对于前台制作订单的过程，需要取到整个过程有关响应时间的指标： 最大响应时间 最小响应时间 平均响应时间 响应时间随时间的变化曲线 服务器性能信息 分析在前台制作订单整个过程中服务器端相应的性能指标值和变化情况： CPU使用率 磁盘I/O情况 内存使用情况 数据库性能（包括缓冲区中获取Buffer的未等待比率、Redo缓冲区获取Buffer的未等待比率、数据块在数据缓冲区中的命中率、内存中的排序率、sql在共享区的命中率、sql语句解析后被重复执行的次数等。） 脚本编写 使用loadrunner来制作销售订单过程的脚本，从进入销售订单FORM开始一直到订单登记并关闭订单FORM截止。 情景设置 各个脚本的并发用户数： Name of Transaction virtual User Num interval(s) 销售订单录入 40       1、按照上表的虚拟用户数量来设置脚本的虚拟用户数量。 2、设置录制订单操作循环10次，也就是一个用户制作10条销售订单。 3、设置压力测试的进度表为：同时启动所有的并发用户。 在这里需要说明：在综合测试中我们使用虚拟用户的数量为50，而在月结压力测试中由于后台请求的繁忙运行和服务器性能的瓶颈，尝试使用50个用户时（审计功能未启用的情况下）结果会产生失败的虚拟用户，为了正确的对比分析审计对系统性能的影响我们使用40个虚拟用户进行测试。 操作步骤 1 停止TL28007测试环境所在服务器上的其他应用。 2 运行总帐管理系统传送程序，STD 科目明细帐和STD 汇总试算表报表这三个请求 3 在TL28007环境中启动nmon 监控系统资源使用情况，启动statpack 监控数据库。 4 在loadrunner中，加载设置的场景，按照设定的参数对系统进行压力测试并间隔的运行statpack获取数据库性能信息。 5 完成后，对loadrunner生成的报表进行分析。 6 对nmon和statpack的结果进行分析。 7 关闭nmon，关闭请求. 8 启用审计功能 9 运行总帐管理系统传送程序，STD 科目明细帐和STD 汇总试算表报表这三个请求 10 在TL28007环境中启动nmon 监控系统资源使用情况，启动statpack 监控数据库。 11  在loadrunner中，加载设置的场景，按照设定的参数对系统进行压力测试并间隔的运行statpack获取数据库性能信息。 12  完成后，对loadrunner生成的报表进行分析。 13  对nmon和statpack的结果进行分析。 测试后期工作 测试完成后收集测试数据，分析测试结果，填写测试报告。 对比内容： 一  ．综合压力测试 1.       前台响应时间 2.       OS性能指标，包括CPU 、I/O、内存； 3.       数据库性能指标，包括缓冲区中获取Buffer的未等待比率、Redo缓冲区获取Buffer的未等待比率、数据块在数据缓冲区中的命中率、内存中的排序率、sql在共享区的命中率、sql语句解析后被重复执行的次数等。 二  .   月结压力测试 1．  前台响应时间 2.     OS性能指标，包括CPU 、I/O、内存； 3.     数据库性能指标，包括缓冲区中获取Buffer的未等待比率、Redo缓冲区获取Buffer的未等待比率、数据块在数据缓冲区中的命中率、内存中的排序率、sql在共享区的命中率、sql语句解析后被重复执行的次数等。 分别分析对比审计启用前后的结果，列出在审计功能启用前后的两个测试结果中各项指标的升降情况。根据分析结果，针对审计功能对系统的影响给出评价。 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 前台响应时间压力测试数据对比分析................. 16 后台性能压力测试数据对比分析.......................... 18 对比压力测试结果分析............................................................ 25 概述 本报告是按照“XXX项目压力测试方案v1.0”文档涉及的方案进行测试操作得到的测试结果数据，并对比审计功能启用前后来分析结果数据，从而分析审计功能对系统的性能影响情况。 由于采用loadrunner作为前台的压力负荷提交工具，是很难实现生产环境使用的多样性和综合性。同时后台的提交也是采用程序提交方式，也必然限定了请求数据的范围。尽管我们选择典型的业务和程序，也不可避免loadrunner的局限性，即无法真实模拟生产环境的应用状况。因此，loadrunner压力测试所带来压力和测试结果数据，只能是在一定程度上模拟。 压力测试实施安排 为合理组织压力测试实施，我们采用下面的综合压力测试和月结压力测试 综合压力测试 环境准备情况 压力测试环境准备为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用户） 业务名称 用户数 间隔时间 打开制作订单页面 50 0s 输入订单头---输入订单行 50 0s 保存 50 0s 登记 50 0s 关闭订单页面 50 0s       我们把每个虚拟用户设置为连续循环10次制作订单，并且所有用户同时载入到系统中（间隔时间0s），这样就足以保证这些用户并发制作销售订单。 3 ） 按照同样的策略，在启用审计功能后再进行测试。 后台性能对比压力测试 1）第一次压力测试（未启用审计功能）期间取得OS和DB的性能数据。 2）第二次压力测试（启用审计功能）期间取得OS和DB的性能数据。 综合压力测试结果数据对比 前台响应时间压力测试数据对比分析 本次压力测试主要关注的是审计功能的启用会给系统带来那些性能的问题，而在此处我们所关心的是整个订单录入响应时的差别，以下是对比分析订单录入整个流程的响应时间分析图： 1）  未启用审计功能前台响应时间 绿色->初始化时间 蓝色->响应时间 2）  启用审计功能前台响应时间 绿色->初始化时间 蓝色->响应时间 对比分析：                                                             从曲线图可以看出，总体响应时间的变化曲线基本一致，审计功能启用后系统处理的时间要稍微长一些，最大的响应时间比审计功能启用前也要长一点，但总体上对系统的影响是很小的。 后台性能压力测试数据对比分析 后台性能数据包括OS性能和DB性能数据 （一） OS性能数据 1.1  CPU占有率和磁盘IO 1）未启用审计功能前 2） 启用审计功能后 对比分析：                                                             从曲线图可以看出，CPU占有率基本一致。在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分钟左右后开始释放内存。 （二） DB性能数据 1）未启用审计功能前 2）启用审计功能后 对比分析：                                                             在以上数据中可以看到启用审计功能后DB性能参数和启用审计功能之前DB性能参数并无明显变化。 月结压力测试 环境准备情况 压力测试环境准备为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用户） 用户数 间隔时间 打开制作订单页面 40 0s 输入订单头---输入订单行 40 0s 保存 40 0s 登记 40 0s 关闭订单页面 40 0s       由于把每个虚拟用户设置为连续循环制作10条订单，并且所有用户同时载入到系统中（间隔时间0s），这样就足以保证这些用户并发制作销售订单。由于服务器性能因素加上后台月结相关请求的运行使得系统的压力非常大，所以我们以40个用户来做性能的样本分析。 3  按照同样的策略，在启用审计功能后再进行测试。 后台性能对比压力测试 1）第一次压力测试（未启用审计功能）期间取得OS和DB的性能数据。 2）第二次压力测试（启用审计功能）期间取得OS和DB的性能数据。 月结压力测试结果数据对比 前台响应时间压力测试数据对比分析 本次压力测试主要关注的是在月结相关请求运行的情况下审计功能的启用会给系统带来那些性能的问题，而在此处我们所关心的是整个订单录入流程响应时间=时的差别，以下对比分析订单录入流程的响应时间分析图： 1）  未启用审计功能前台响应时间 绿色->初始化时间 蓝色->响应时间 2）  启用审计功能前台响应时间 绿色->初始化时间 蓝色->响应时间 对比分析：                                                             从曲线图可以看出，总体响应时间的变化曲线非常相似，说明在月结程序运行的状态下审计对系统性能的影响比率进一步降低了。 后台性能压力测试数据对比分析 后台性能数据包括OS性能和DB性能数据 （一）OS性能数据 1.1  CPU占有率和磁盘IO 1）未启用审计功能前 2） 启用审计功能后 对比分析：                                                             从曲线图可以看出，CPU占有率基本一致。在IO方面后者有一个磁盘IO的峰值在1200/sec，比前者多出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性能参数，这些数据在审计功能启用的前后变化并不明显，所以审计功能对系统的整体性能影响并不大。