grinder压力测试报告模板.docx

grinder压力测试报告模板.docx

《grinder压力测试报告模板.docx》由会员分享，可在线阅读，更多相关《grinder压力测试报告模板.docx（11页珍藏版）》请在冰豆网上搜索。

grinder压力测试报告模板

XXXXXX有限公司

渠道管理系统（CMS）

压力测试文档

2007年12月

修正记录

创建日期

版本号

创建人

审查人

1.测试原理

压力（负载）测试技术在各种极限情况下对产品进行测试（如很多人同时使用该软件，或者反复运行该软件），以检查产品的长期稳定性。

例如，使用压力测试工具对web服务器进行压力测试。

本项测试可以帮助找到一些大型的问题，如死机、崩溃、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩溃。

基于J2EE平台的应用程序一般分为两个基本类别：

交互式的－即终端用户与应用程序同步交互；批处理或后端应用程序－即不需要直接与终端用户交互。

对于交互式应用程序，性能一般是通过大小和规划问题的容量来定义，评测标准可以为同时发生的用户数量和响应时间；对于后者，性能统计量是吞吐量，评测标准之一是每秒的事务处理，而事务处理在具体的场合定义可能有所不同。

比如对于Servlet，事务处理可能为一个请求。

而对JMS，吞吐量可能就是消息。

2.测试环境

2.1测试环境网络拓扑图：

图表1

2.2硬件列表：

2.2.1.WEB服务器：

型号（SUNFire280R）：

处理器类型：

UltraSPARCIII（900HZ），

内存：

1G，OS:

Solaris8

2.2.2.数据库服务器：

型号：

处理器类型：

P4，内存：

1G，磁盘：

40G，OS：

Win2000server

2.2.3.测试机3台：

型号：

处理器类型：

P4，内存：

1G，磁盘：

１×80G，OS：

WinXPProfessional

（分别命名为测试机器一、测试机器二、测试机器三）。

2.2.4.其他：

其他网络设备等。

2.3软件列表：

①中心应用程序服务器：

Tomcat5.5.25

②数据库：

DB2（9）forWindows

③Java虚拟机：

JRE1.6.2

④测试工具:

TheGrinder3

⑤浏览器：

FireFox2.0，IE6等

3.测试工具—TheGrinder3介绍

TheGrinder是一个开源的负载生成/数据收集工具，它本身是Java应用程序，需要在安装JVM（版本不能低于1.3）的平台上运行，可以在下载。

下在后的文件为grinder-3.0-beta33.zip，解压这个包到磁盘上。

解压后的目录结构为：

图表3

其中“lib”目录下是你运行测试工具是所需要的JAR包。

因此在系统的环境变量中添加lib目录下的所有JAR包，如图所示：

图表4

注：

所有的测试机器都要安装和配置TheGrinder。

Grinder能提供响应时间、吞吐量等性能测度。

它有三种进程：

工人进程，是由Grinder代理进程创建的，负责执行单独的测试；代理进程，负责管理该机器上的工人进程；控制台，协同其他进程工作并收集统计数据。

它有四个独特的方面：

负载生成、请求定义、统计记录和控制台。

负载生成的原理是这样的：

为了运行一组给定的测试，需要在每个测试机上启动一个代理进程。

该代理进程负责创建许多工人进程。

每个工人进程加载一个确定需要运行的测试类型的插件组件，然后启动多个工人线程。

负载的数目＝（代理进程数）×（工人进程数）×（工人线程数）。

控制台的启动命令：

javanet.grinder.Console

代理进程启动命令：

javanet.grinder.Grinder　（默认的启动脚本是当前目录下的grinder.properties文件）

grinder.properties文件中的grinder.processes和grinder.threads属性分别设置工人进程数和工人线程数。

TheGrinder带有一个称为TCPProxy的工具，通过运行命令：

javanet.grinder.TCPProxy–console–http>grinder.py

还要修改浏览器的连接设置如图１所示：

图表5

此时能自动的获取对应与用户使用浏览器做出的HTTP请求的测试脚本项，并生成响应的测试脚本条目。

在Grinder中将事务定义为Grinder测试脚本中一个单独的请求。

TheGrinder控制台是一个有用的TheGrinder工作方式和报告工具的接口，可以聚集来自工人进程的报告同时收集统计数据，并以定期的采样间隔更新其显示。

如图２所示，选择标签Graphs（图形）可以图形显示事务处理每秒；选择Result（结果）标签可以以表格形式查看结果。

图6

4.定义测试脚本

使用TheGrinder自带的TCPProxy工具，模拟单个用户登录系统，生成性能测试脚本中用到的请求序列及要手工输入的文件。

如录制的脚本文件主要有主页，登录页，登录后系统页面，机构查询页面等请求页面。

录制并修改三个测试脚本分别的三台测试机器上运行。

在测试机器一上运行测试脚本一，它主要是登录后进行机构的查询，包过模糊查询和条件查询。

在测试机器二上运行测试脚本二，它主要是登录后进行DM人员的增加。

在测试机器三上运行测试脚本三，它主要是登录后进行查询银保人员的基本信息，包过模糊查询和条件查询。

设置测试机器一的启动脚本“grinder.properties”中的grinder.processes，grinder.threads和grinder.runs分别为2，15和20；

设置测试机器二的启动脚本“grinder.properties”中的grinder.processes，grinder.threads和grinder.runs分别为2，15和20；

设置测试机器三的启动脚本“grinder.properties”中的grinder.processes，grinder.threads和grinder.runs分别为2，20和20；

5.定义采样方法

采样方法是指如何精确地收集性能数据，以及哪种度量将对最终分析的结果有贡献。

在TheGrinder中有两种采样方法：

固定的周期数（周期方法）和固定的时间（快照方法）,所选择的方法依赖于性能测试的目标。

周期是指一个模拟用户对一个测试脚本的完整执行。

6.执行测试

javanet.grinder.Console//启动TheGrinder控制台。

javanet.grinder.Grindergrinder.properties//执行测试脚本，grinder.properties是启动测试时默认的配置文件，也可以。

其它一些参数的设置请参阅TheGrinder的官方文档。

可以是设置三台测试机中的一台外数据采集机器，即其它两台测试机器产生的数据都发送给那一台机器。

这样更有利用数据的采集和整理。

具体做法如下：

1．假设测试机器一为信息采集的主机，IP地址为192.168.0.11。

2．在另外两台测试机器中，在执行测试脚本的目录中找到grinder.properties文件。

3．打开grinder.properties文件，添加下面两行：

grinder.consoleHost=192.168.0.11

grinder.consolePort=6372

grinder.script=ybrwcx1.py

grinder.consoleHos的值为测试机器一的IP。

grinder.consolePort的值为测试机器一Console代理默认端口号。

grinder.script的值为测试的脚本文件名。

4．保存后再执行测试脚本命令，就可以达到我们想要的结果了。

注意：

测试机在执行测试的过程中，可能会出现测试中止的情况，这是由于你在grinder.properties配置文件中grinder.threads设置的过多导致内存不够，可以在grinder.properties中添加“grinder.jvm.arguments=-mx512m”一行，grinder.jvm.arguments大小据实际情况而定。

7.实际性能测试及结果

 以下测试数据是服务器和数据库主机在一台普通PC机上的情况。

在测试过程中300人以下并发用户系统可以承受住，但当用户数目达到500时，CPU和内存的使用量剧增，就会发生应用程序崩溃死机等，图3中我们只给出100个并发用户的测试数据。

图7

表1100个并发用户的测试数据

并发用户数与事务执行情况

Web服务器

并发用户数

ART（ms）

事务成功率

CPU利用率（最大）

内存利用率

100

2184

99.94%

92%

68.11%（不确定）

表1中可以看出100个并发用户登录系统页面的ART，MART等参数。

可以看出此时系统绝大部分时间还能正常访问。

8.性能分析、调整及结果

影响系统性能的因素有很多：

计算机硬件、数据库的访问速度、Java虚拟机（JavaVirtualMachines,JVM）,TCP/IP堆栈、Web服务器、网络、操作的复杂度等。

可以从以下几个方面来优化系统性能（没有在该应用程序的代码和体系结构上再做调整）：

1.在计算机硬件性能和结构方面所做的调整

2.将WEB服务和DBS服务分开

3.在Java虚拟机（JVM）参数方面的调整

JVM对性能影响最大的就是其堆的大小及其分配情况。

JVM的堆大小决定了JVM花费在收集垃圾上的时间和频度，通常情况下,我们建议使用可用内存（除操作系统和其他应用程序占用之外的内存）70-80%,为避免堆大小调整引起的开销,设置内存堆的最小值等于最大值即:

-Xms（指定在启动JVM时为堆所分配的内存大小）=-Xmx（指定Java解释器将用于动态分配对象和数组的最大堆的大小）。

而为了防止内存溢出,建议在生产环境堆大小至少为256M（Platform至少512M）,实际环境中512M~1G左右性能最佳,2G以上是不可取的。

因在测试过程中，通过设置Xms和Xmx将参数调节到最佳组合状态，从而提高系统性能。

4.在应用服务器（如Tomcat）的参数方面的调整

应用服务器的主要参数有线程数、最大会话闲置时间，因配置了数据库连接池，那么还有最大数据库连接数、最大连接闲置时间等。

9.结论

通过压力测试及相应的性能优化策略的实施，我们最终得到的测试结果为：

CMS系统在本测试环境下300左右的用户同时登录和查询机构等操作的平均响应时间为2秒。

系统的成功率平均为99.94％。

10．佣金计算

计算日期区间：

2007年1月

至2007年10月

渠道：

Bank.DMTM

分公司数：

9

BaseCommissionRun：

18

并发数：

10

CommissionEvent：

CommissionDetail：

计算时间：

系统错误数：

0

区间

渠道

分公司数

BaseCommissionRun

并发数

CommssionEvent

CommissionDetail

时间

系统错误

9

18