人力资源grinder压力测试报告模板资料文档格式.docx
《人力资源grinder压力测试报告模板资料文档格式.docx》由会员分享,可在线阅读,更多相关《人力资源grinder压力测试报告模板资料文档格式.docx(9页珍藏版)》请在冰豆网上搜索。
对于后者,性能统计量是吞吐量,评测标准之一是每秒的事务处理,而事务处理在具体的场合定义可能有所不同。
比如对于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台:
1×
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
还要修改浏览器的连接设置如图1所示:
图表5
教师的专业成长ppt此时能自动的获取对应与用户使用浏览器做出的HTTP请求的测试脚本项,并生成响应的测试脚本条目。
推进一带一路建设既要在Grinder中将事务定义为Grinder测试脚本中一个单独的请求。
TheGrinder控制台是一个有用的TheGrinder工作方式和报告工具的接口,可以聚集来自工人进程的报告同时收集统计数据,并以定期的采样间隔更新其显示。
如图2所示,选择标签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:
计算时间:
系统错误数:
区间
渠道
分公司数
BaseCommissionRun
并发数
CommssionEven