grinder压力测试报告模板

1、XXXXXX渠道管理系统（ CMS）压力测试文档2007 年 12 月修正记录创建日期版本号创建人审查人目录1.测试原理 .42.测试环境 .42.1测试环境网络拓扑图： . .42.2硬件列表： . .52.2.1. WEB 服务器： .52.2.2.数据库服务器： . .52.2.3.测试机 3 台： . .52.2.4. 其他： . .52.3 软件列表： .53.测试工具 The Grinder3 介绍 .54.定义测试脚本.85.定义采样方法.96.执行测试 .97.实际性能测试及结果 .98.性能分析、调整及结果 .109.结论.1110佣金计算 .111. 测试原理压力（负载）测

2、试技术在各种极限情况下对产品进行测试( 如很多人同时使用该软件，或者反复运行该软件) ，以检查产品的长期稳定性。例如，使用压力测试工具对web 服务器进行压力测试。本项测试可以帮助找到一些大型的问题，如死机、崩溃、存泄漏等，因为有些存在存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，存泄漏得越来越多，就会导致系统崩溃。基于 J2EE 平台的应用程序一般分为两个基本类别：交互式的即终端用户与应用程序同步交互；批处理或后端应用程序即不需要直接与终端用户交互。对于交互式应用程序，性能一般是通过大小和规划问题的容量来定义 ，评测标准可以为同时发生的用户数量和响应时间；对于后

3、者，性能统计量是吞吐量，评测标准之一是每秒的事务处理，而事务处理在具体的场合定义可能有所不同。比如对于 Servlet ，事务处理可能为一个请求。而对 JMS，吞吐量可能就是消息。2. 测试环境2.1测试环境网络拓扑图：图表 12.2硬件列表：服务器：型号（ SUN Fire 280R ）：处理器类型： UltraSPARC III（ 900HZ），存： 1G，OS: Solaris 8数据库服务器：型号：处理器类型：P4，存： 1G，磁盘： 40G， OS： Win2000server测试机 3 台：型号：处理器类型：P4，存： 1G，磁盘：×80G， OS： WinXP Prof

4、essional（分别命名为测试机器一、测试机器二、测试机器三）。其他：其他网络设备等。2.3 软件列表： 中心应用程序服务器： 数据库： DB2(9) for Windows Java 虚拟机： 测试工具 : The Grinder3 浏览器： FireFox2.0，IE6 等3.测试工具 The Grinder3介绍安装The Grinder是一个开源的负载生成/ 数据收集工具，它本身是Java 应用程序，需要在JVM（版本不能低于1.3）的平台上运行 ，可以在 下载。下在后的文件为grinder-3.0-beta33.zip，解压这个包到磁盘上。解压后的目录结构为：图表 2其中“ lib

5、 ”目录下是你运行测试工具是所需要的JAR包。因此在系统的环境变量中添加 lib目录下的所有JAR包，如图所示：图表 3注：所有的测试机器都要安装和配置The Grinder。Grinder能提供响应时间 、吞吐量等性能测度。它有三种进程 ：工人进程， 是由 Grinder代理进程创建的 ，负责执行单独的测试 ；代理进程 ，负责管理该机器上的工人进程 ；控制台，协同其他进程工作并收集统计数据。它有四个独特的方面：负载生成、请求定义、统计记录和控制台。负载生成的原理是这样的：为了运行一组给定的测试，需要在每个测试机上启动一个代理进程。该代理进程负责创建许多工人进程。每个工人进程加载一个确定需要运

6、行的测试类型的插件组件，然后启动多个工人线程。负载的数目（代理进程数）×（工人进程数）×（工人线程数）。控制台的启动命令：代理进程启动命令：( 默认的启动脚本是当前目录下的perties文件 )perties文件中的cesses和 grinder.threads属性分别设置工人进程数和工人线程数。The Grinder带有一个称为TCPProxy 的工具，通过运行命令：console http > grinder.py还要修改浏览器的连接设置如图所示：图表 4此时能自动的获取对应与用户使用浏览器做出的H

7、TTP请求的测试脚本项，并生成响应的测试脚本条目。在 Grinder中将事务定义为Grinder测试脚本中一个单独的请求。The Grinder控制台是一个有用的The Grinder工作方式和报告工具的接口，可以聚集来自工人进程的报告同时收集统计数据，并以定期的采样间隔更新其显示。如图所示，选择标签Graphs （图形）可以图形显示事务处理每秒；选择Result （结果）标签可以以表格形式查看结果。图 54. 定义测试脚本使用 The Grinder自带的 TCPProxy 工具，模拟单个用户登录系统，生成性能测试脚本中用到的请求序列及要手工输入的文件。如录制的脚本文件主要有主页，登录页，登

8、录后系统页面，机构查询页面等请求页面。录制并修改三个测试脚本分别的三台测试机器上运行。在测试机器一上运行测试脚本一，它主要是登录后进行机构的查询，包过模糊查询和条件查询。在测试机器二上运行测试脚本二，它主要是登录后进行DM人员的增加。在测试机器三上运行测试脚本三，它主要是登录后进行查询银保人员的基本信息，包过模糊查询和条件查询。设置测试机器一的启动脚本“perties”中的 cesses，grinder.threads和 grinder.runs分别为 2， 15 和 20；设置测试机器二的启动脚本“perties”中的 gri

9、cesses，grinder.threads和 grinder.runs分别为 2， 15 和 20；设置测试机器三的启动脚本“perties”中的 cesses，grinder.threads和 grinder.runs分别为 2， 20 和 20；5. 定义采样方法采样方法是指如何精确地收集性能数据，以及哪种度量将对最终分析的结果有贡献。 在The Grinder 中有两种采样方法：固定的周期数 ( 周期方法 ) 和固定的时间 ( 快照方法 ), 所选择的方法依赖于性能测试的目标。周期是指一个模拟用户对一个测试脚本的完整执行。6.

10、 执行测试启动 The Grinder控制台。执行测试脚本，perties是启动测试时默认的配置文件，也可以。其它一些参数的设置请参阅The Grinder的官方文档。可以是设置三台测试机中的一台外数据采集机器，即其它两台测试机器产生的数据都发送给那一台机器。这样更有利用数据的采集和整理。具体做法如下：1假设测试机器一为信息采集的主机，IP 地址为。2在另外两台测试机器中，在执行测试脚本的目录中找到perties文件。3打开 perties文件，添加下面两行：grinder.consolePort=6372grinder.scr

11、ipt=ybrwcx1.pygrinder.consoleHos的值为测试机器一的IP 。grinder.consolePort的值为测试机器一Console 代理默认端口号。grinder.script的值为测试的脚本文件名。4保存后再执行测试脚本命令，就可以达到我们想要的结果了。注意：测试机在执行测试的过程中，可能会出现测试中止的情况，这是由于你在perties配置文件中grinder.threads设置的过多导致存不够，可以在perties中添加“”一行，大小据实际情况而定。7. 实际性能测试及结果以下测试数据是服务器和数据库主机在一台普通PC

12、机上的情况。在测试过程中300 人以下并发用户系统可以承受住，但当用户数目达到500 时， CPU和存的使用量剧增，就会发生应用程序崩溃死机等，图3 中我们只给出100 个并发用户的测试数据。图 6表1 100个并发用户的测试数据并发用户数与事务执行情况Web 服务器并发用户数ART(ms)事务成功率CPU利用率存利用率（最大）100218499.94%92%68.11%( 不确定 )表 1 中可以看出 100 个并发用户登录系统页面的部分时间还能正常访问。ART，MART等参数。可以看出此时系统绝大8. 性能分析、调整及结果影响系统性能的因素有很多：计算机硬件、数据库的访问速度、Java 虚

13、拟机 (JavaVirtual Machines,JVM),TCP/IP堆栈、 Web 服务器、网络、操作的复杂度等。可以从以下几个方面来优化系统性能（没有在该应用程序的代码和体系结构上再做调整）：1. 在计算机硬件性能和结构方面所做的调整2. 将 WEB服务和 DBS服务分开3. 在 Java 虚拟机 (JVM) 参数方面的调整JVM对性能影响最大的就是其堆的大小及其分配情况。JVM 的堆大小决定了JVM 花费在收集垃圾上的时间和频度，通常情况下 , 我们建议使用可用存( 除操作系统和其他应用程序占用之外的存)70-80%, 为避免堆大小调整引起的开销, 设置存堆的最小值等于最大值即 :-X

14、ms( 指定在启动JVM 时为堆所分配的存大小)=-Xmx( 指定 Java解释器将用于动态分配对象和数组的最大堆的大小) 。而为了防止存溢出, 建议在生产环境堆大小至少为256M(Platform 至少 512M), 实际环境中 512M1G左右性能最佳 ,2G 以上是不可取的。因在测试过程中，通过设置 Xms和 Xmx将参数调节到最佳组合状态，从而提高系统性能。4. 在应用服务器 ( 如 Tomcat) 的参数方面的调整应用服务器的主要参数有线程数、最大会话闲置时间，因配置了数据库连接池，那么还有最大数据库连接数、最接闲置时间等。9. 结论通过压力测试及相应的性能优化策略的实施，我们最终得到的测试结果为：CMS系统在本测试环境下300 左右的用户同时登录和查询机