数据库压力测试方案Word文档下载推荐.docx

数据库压力测试方案Word文档下载推荐.docx

《数据库压力测试方案Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《数据库压力测试方案Word文档下载推荐.docx（8页珍藏版）》请在冰豆网上搜索。

1、数据库的并发数量：

即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。

2、服务器的CPU、I/O和内存使用率：

即在各种负载压力情况下，服务器系统CPU处理时间，I/O的读写频率和内存的使用状况。

3、数据库的可靠性：

即在连续工作时间状态下，系统能够正常运行的时间，即在连续工作时间段内没有出错信息。

1.2系统结构及流程（填写客户端配置）

MES客户端在实际生产中的体系结构跟本次性能测试所采用的体系结构是一样的，交易流程也完全一致的。

不过，由于硬件条件的限制，本次性能测试的硬件平台跟实际生产环境略有不同。

1.2.1系统总体结构

MES客户端架构

为提高产线客户端的用户响应速度，MES采集客户端采用逻辑封装Oracle、后台异步执行的架构：

Ø

MES终端直接连接Oracle数据库；

MES业务逻辑，封装在Oracle数据库Package中；

MES终端采用异步提交的模式，扫码时将条码保存到文本文件，后台定时将文本文件内容提交到Pacakge执行；

1.2.2功能模块（填写客户端采集流程）

1．本次性能测试中各类操作都是由若干功能模块组成的，每个功能都根据其执行特点分成了若干操作步骤，每个步骤就是一个功能点（即功能模块），本次压力测试主要涉及的功能模块以及所属操作如下表业务流程

本次性能测试中，选择的各类交易的业务流程如下：

查询的业务流程只是单一步骤的，即：

输入查询条件后获取查询结果，因此在本次性能测试中只作为一个事务处理。

1.2.3关键点描述（KP）

本次性能测试的关键点，就是查看数据库在不同用户数量（并发）压力下的表现，即：

支持的并发用户数目和并发用户发送频率，以及在较大压力下，系统的处理能力以及CPU、数据库I/O和内存的使用情况，并找出相应的性能瓶颈。

1.3性能测试环境

本次性能测试环境与真实运行环境硬件和网络环境有所不同，是真实环境的缩小，数据库是真实环境数据库的一个复制（或缩小），本系统采用标准的CS结构，客户端通过前台安装访问应用系统。

其中具体的硬件和网络环境如下：

（填写IBMP750）

中间件服务器：

Weblogic9

操作系统：

Windows2003/Solaris10

网络环境：

LAN（10M）

数据库：

Oracle10gRAC

客户端：

PC（Windows）

网络拓扑和结构图如下：

2第二章性能测试

从广泛意义上讲性能测试包括：

压力测试、稳定性测试、负载能力测试和可扩展性测试等。

在不同应用系统的性能测试中，需要根据应用系统的特点和测试目的的不同来选择具体的测试方案，本次数据库的性能测试主要是采用通常的压力测试模式来执行的，即：

逐步增加压力，查看应用系统在各种压力状况下的性能表现。

在本次性能测试中，将使用美科利（Mercury）公司的性能测试LoadRunner11对测试应用的各层进行监控，判断J2EE各层次的各类方法和类的调用使用时间和效率，并帮助开发人员分析J2EE应用的各类操作的性能瓶颈点。

2.1压力测试

在性能测试中，压力测试主要是为了获取系统在较大压力状况下的性能表现而设计并实现的，压力测试主要是获取系统的性能瓶颈和系统的最大吞吐率。

2.1.1压力测试概述

本次测试是针对数据库在应对密集整转的压力下业务处理能力的测试，检验系统的吞吐率。

本系统的压力测试主要是针对主要业务功能客户端采集应用高峰时期，并发用户数较多的时候的处理能力等。

2.1.2测试目的

压力测试的目的就是检验系统的最大吞吐量，检验现行的业务系统在各种压力交易量下的运行状况，检验系统地运行瓶颈，获取系统的处理能力等等。

本次针对MES系统所进行的压力测试的测试目的为：

✧给出数据库当前的性能状况

✧定位数据库性能瓶颈或潜在性能瓶颈

✧总结一套合理的、可操作的、适合公司现实情况的性能测试方案，为后续的性能测试工作提供基本思路。

2.1.3测试方法及测试用例

使用美科利公司（Mercury）的性能测试软件LoadRunner，对现行的NES系统进行脚本录制、测试回放、逐步加压和跟踪记录。

测试过程中，由LoadRunner的管理平台调用各台测试前台，发起各种组合的交易请求，并跟踪记录服务器端的运行情况和返回给客户端的运行结果。

使用的测试方法用例包括：

（1、自动文本扫码2、loadrunner用例）

业务类型

用例一

用例二

用例三

上线

装压缩机

合格品采集

下线采集

针对每个测试用例，都将采用逐步加压和瞬间加压两种客户端连接方式进行，查看服务器端在客户端的连接数量变化过程中对应的处理能力，以更好的定位系统在达到多少并发或压力下我们的系统出现了不稳定。

2.1.4测试指标及期望

在本次性能测试中，各类测试指标包括测试中应该达到的某些性能指标，这些性能指标均是来自数据库设计开发时遵循的业务需求，当某个测试的某一类指标已经超出了业务需求的要求范围，则测试已经达到目的，即可终止压力测试。

2.1.4.1数据库级别的测试指标：

（需要DBA预先评估什么值情况稳定）

✓CPU的利用率小于40%

✓内存占用小于80%

✓Processorqueuelength小于2

✓Responsetime小于1s

✓吞吐量throughtput大于90%

✓业务执行的平均响应时间（期望值：

<

15s）

✓不同并发用户数的状况下的记录上述值

2.1.4.2网络级别的测试指标：

（异地测试需要评估）

✓吞吐量：

单位时间内网络传输数据量

✓冲突率：

在以太网上监测到的每秒冲突数

2.1.4.3服务器操作系统级别的测试指标：

✓进程/线程交换率：

进程和线程之间每秒交换次数

✓CPU利用率：

即CPU占用率（％）

✓系统CPU利用率：

系统的CPU占用率（％）

✓用户CPU利用率：

用户模式下的CPU占用率（％）

✓磁盘交换率：

磁盘交换速率

✓中断速率：

CPU每秒处理的中断数

2.1.4.4数据库级别的测试指标：

（DBA评估）

✓数据库I/O的流量大小

✓数据库锁资源的使用数量

✓数据库的并发连接数：

客户端的最大连接数

2.1.5测试数据准备

2.1.5.1案例数据：

满负荷压力（）

根据测试系统的硬件条件，选择满负荷的压力，在系统的资源使用基本维持在90%左右的状况下，测试数据库的处理能力。

数据准备工作包括：

测试数据库需具备与真实环境成一定比例或基本一致的数据

2.1.6运行状况记录（测试后填写）

记录可扩展性测试中的测试结果及其系统的运行状况。

除了记录测试指标以外，应该结合测试实时记录系统各个层次的资源和参数。

主要包括：

✓硬件环境资源

✓服务器操作系统参数

✓网络相关参数

✓数据库相关参数：

具体数据库参数有所不同，结合各个数据库独有的特点记录

3第三章测试过程及结果描述

3.1测试描述

在测试数据准备完备以后，测试将进行。

记录每次测试的结果数据，分析测试结果对系统进行全面评估。

3.2测试场景（需要测试填写）

测试中，使用逐步加压的模式，测试运行场景安排如下：

1.每隔2秒增加1个用户连接，最多增加到100个用户，查看并记录运行情况

2.每隔2秒增加2个用户连接，最多增加到200个用户，查看并记录运行情况

3.每隔2秒增加1个用户连接，最多增加到300个用户，查看并记录运行情况

4.每隔3秒增加1个用户连接，最多增加到400个用户，查看并记录运行情况

每个场景都包括：

用户登录-业务操作-业务完成-退出系统，所有用例都按以上场景进行测试，由于pc性能限制，为了更准确模拟现场环境，将运行的所有脚本部署在8台LoadRunner终端上，主要目的就是检查在不同的压力的情况下，业务系统的性能表现。

已申请10台虚拟机，配置为Windows2003、2.67GHz双核CPU、4G内存。

在10台虚拟机上部署采集客户端，每台部署15个终端，每个测试终端隔1秒生成一个条码模拟文件，即模拟每秒并发量150次。

3.3测试结果

执行每个场景时记录以下相应的数据

数据库（Oracle）服务器上主机上的CPU利用率：

IO和CPU利用率对照表如下：

DB服务器上监控的网络流量：

运行的并发用户数目：

测试中完成各操作的平均响应时间：

（单位：

秒）

测试中每秒的点击率如下：

交易的吞吐率（每秒处理数据量）：

4第四章测试报告

在XXX系统的性能测试结束，根据测试结果，将生成测试报告。

对应的文档名称如下：

✓《性能测试报告》