您现在的位置：&&>>&&>>&&>>&&>>&正文
JMeter技巧集锦
　　JMeter 是一个流行的用于负载的开源工具， 具有许多有用的功能元件，如线程组（thread group）， 定时器（timer）， 和HTTP 取样 (sampler) 元件。 本文是对JMeter 用户手册的补充，而且提供了关于使用Jmeter的一些模拟元件开发质量脚本的指导。　　本文同时也讨论了一项重要的内容：在指定了精确的响应时间要求后，如何来校验测试结果，特别是在采用了置信区间分析这种严格的统计方式的情况下应如何操作。请注意，我假定本文的读者们了解关于Jmeter的基础知识，本文的例子基于Jmeter2。0。3版。 　　确定一个线程组的ramp-up period （Determine）　　Jmeter脚本的第一个要素是线程组（Thread Group），因此首先让我们来回顾一下。 正如图一所示，线程组需要设置以下参数： 　　?线程数量。 　　?ramp-up period。 　　?运行测试的次数。 　　?启动时间:立即或者预定的时间，如果是后者，线程组所包含的元素也要指定这个起止时间。
　　图 1。 JMeter 线程组（JMeter Thread Group）　　每个线程均独立运行测试计划。因此， 线程组常用来模拟并发用户访问。如果客户机没有足够的能力来模拟较重的负载，可以使用Jmeter的分布式测试功能来通过一个Jmeter控制台来远程控制多个Jmeter引擎完成测试。 　　参数 ramp-up period 用于告知JMeter 要在多长时间内建立全部的线程。默认值是0。如果未指定ramp-up period ，也就是说ramp-up period 为零， JMeter 将立即建立所有线程，假设ramp-up period 设置成T 秒， 全部线程数设置成N个， JMeter 将每隔T/N秒建立一个线程。 　　线程组的大部分参数是不言自明的，只有ramp-up period有些难以理解， 因为如何设置适当的值并不容易。 首先，如果要使用大量线程的话，ramp-up period 一般不要设置成零。 因为如果设置成零，Jmeter将会在测试的开始就建立全部线程并立即发送访问请求， 这样一来就很容易使饱和，更重要的是会隐性地增加了负载，这就意味着将可能过载，不是因为平均访问率高而是因为所有线程的第一次并发访问而引起的不正常的初始访问峰值，可以通过Jmeter的聚合报告监听器看到这种现象。 这种异常不是我们需要的，因此，确定一个合理的ramp-up period 的规则就是让初始点击率接近平均点击率。当然，也许需要运行一些测试来确定合理访问量。 　　基于同样的原因，过大的ramp-up period 也是不恰当的，因为将会降低访问峰值的负载，换句话说，在一些线程还未启动时，初期启动的部分线程可能已经结束了。 　　那么，如何检验ramp-up period I太小了或者太大了呢？首先，推测一下平均点击率并用总线程除点击率来计算初始的ramp-up period。 例如，假设线程数为100， 估计的点击率为每秒10次， 那么估计的理想ramp-up period 就是 100/10 = 10 秒。 那么，应怎样来提出一个合理的估算点击率呢？没有什么好办法，必须通过运行一次测试脚本来获得。　　其次， 在测试计划（test plan）中增加一个聚合报告监听器，如图2所示，其中包含了所有独立的访问请求（一个samplers）的平均点击率。 第一次取样的点击率（如http请求）与ramp-up period 和线程数量密切相关。通过调整ramp-up period 可以使首次取样的奠基率接近平均取样的点击率。
　　图2 JMeter 聚合报告 　　第三， 查验一下Jmeter日志(文件位置：JMeter_Home_Directory/bin) 的最后一个线程开始时第一个线程是否真正结束了，二者的时间差是否正常。　　总之，是否能确定一个适当的ramp-up time 取决于以下两条规则: 　　?第一个取样器的点击率（hit rate）是否接近其他取样器的平均值，从而能否避免ramp-up period 过小。　　?在最后一个线程启动时，第一个线程是否在真正结束了，最好二者的时间要尽可能的长，以避免ramp-up period过大。　　有时，这两条规则的结论会互相冲突。 这就意味着无法找到同时满足两条规则的合适的ramp-up period。 糟糕的测试计划通常会导致这些问题，这是因为在这样的测试计划里，取样器将不能充分地采集数据，可能因为测试计划执行时间太短并且线程会很快的运行结束。 　　用户思考时间（User think time），定时器，和代理服务器（proxy server）　　在负载测试中需要考虑的的一个重要要素是思考时间（think time）， 也就是在两次成功的访问请求之间的暂停时间。 有多种情形挥发导致延迟的发生： 用户需要时间阅读文字内容，或者填表， 或者查找正确的链接等。未认真考虑思考时间经常会导致测试结果的失真。例如，估计数值不恰当，也就是被测系统可以支持的最多用户量（并发用户）看起来好像要少一些等。 　　Jmeter提供了一整套的计时器（timer）来模拟思考时间（think time）， 但是仍旧存在一个问题：: 如何确定适当的思考时间呢？幸运的是， JMeter 提供了一个不错的答案：使用 JMeter HTTP 代理服务器（Proxy Server）元件。 　　代理服务器会记录在使用一个普通的浏览器（如FireFox 或 Internet Explorer）浏览一个web应用时的操作。 另外， JMeter 在记录操作的同时会建立一个测试计划（test plan）。 这个功能能提供以下便利： 　　?不必手工建立HTTP 访问请求， 尤其是当要设置一些令人乏味的参数时（然而，非英文的参数也许不能正常工作) 。JMeter 将会录制包括隐含字段（hidden fields）在内的所有内容。 　　?在生成的测试计划中，Jmeter会包含浏览器生成的所有的 HTTP 报头，如User-Agent (e。g。， Mozilla/4。0)， 或AcceptLanguage (e。g。， zh-tw，en-q=0。7，zh-q=0。3)等。 　　?JMeter 会根据设置在录制操作的同时建立一些定时器，其延迟时间是完全根据真实的操作来设置的现在让我们来看一下如何配置Jmeter的录制功能。 在JMeter 的控制台上， 在工作台（WorkBench）元件上单击右键，然后选择”add the HTTP Proxy Server “。 注意是在WorkBench 上单击右键而不是在Test Plan上， 因为现在是要为记录操作进行配置而不是要运行测试计划。&&HTTP Proxy Server 的实现原理就是通过配置浏览器的代理服务器而使所有的访问请求通过JMeter发送（，因而被Jmeter把访问过程录制下来）。 　　如图3所示， HTTP代理服务器（HTTP Proxy Server）元件的一些参数必须被配置: 　　?端口(port): 代理服务器的监听端口 　　?目标控制器（Target Controller）: 是代理用于生成的数据的控制器，默认情况下，， JMeter 将会在当前的测试计划中找一个记录用的控制器用于，此外也可以在下拉菜单中选择任意控制起来存储，通常默认值就可以了。 　　?分组(Grouping): 确定在测试计划中如何来为生成的元件分组。 有多个选项， 一般可以选择“只存储每个组的第一个样本”，否则，将会原样录制URLs，包括包含图像和Scripts脚本的页面。当然 也可以尝试一下默认值“不对样本分组”（"Do not group samples"），来看一下JMeter 建立的原版的测试计划。 　　?包含模式(Patterns to Include) 和 排除模式(Patterns to Exclude) :帮助过滤一些不需要的访问请求。
　　图 3。 JMeter 代理服务器(Proxy Server)。　　当你点击开始（Start）按钮时，代理服务器就会开始记录所接受的HTTP 访问请求。 当然，在开始记录前，要首先设置好浏览器的代理服务器设置。在代理服务器元件中可以增加一个定时器子元件（配置元件），用于告知Jmeter来在其生成的HTTP请求中自动的增加一个定时器。Jmeter会自动把实际的延迟时间存储为一个被命名为T的Jmeter变量，因此，如果在代理服务器元件里使用了高斯随机定时器，就应该在其中的固定延迟偏移（Constant Delay Offset）设置项里添上${T}（用于自动引用纪录的延迟时间），如图4所示。这是另一个节省时间的便利特性。
　　图 4。 在代理服务器组建中增加一个高斯随机定时器 　　定时器将会使相应的的取样器被延迟。 延时的规则是，在上一个访问请求被响应并延时了指定的时间后，下一个被定时器影响的取样访问请求才会被发送出去。 因此， 你必须手工删除第一个取样器中自动生成的定时器，因为第一个取样器不需要定时器。 　　在启动HTTP代理服务器以前，要在测试计划中增加一个线程组（thread group），在线程组中增加一个录制控制器（recording controller）用于存储生成的结果。 否则， 生成的元件将会被直接添加到工作台里。另外， 在录制控制器里增加一个HTTP请求默认值元件HTTP Request Defaults 元件 (是一个配置元件) 也很重要，这样Jmeter就不填写使用了默认值的字段。 　　录制完成后， 停止HTTP 代理服务器; 在录制控制器元件上单击右键将记录的元件保存为一个文件用于以后重用，另外，不要忘了恢复浏览器的代理服务器设置。 　　指定响应时间需求并校验结果&&&&　尽管本节内容与Jmeter不是直接相关，但是Jmeter仍旧是指定响应时间需求和校验测试结果这两个负载测试评价任务互相联系的纽带。　　在web应用的环境里，响应时间指的是从提交访问请求到等到HTML结果所耗费的时间。从技术的角度看，响应时间也应包括浏览器重绘HTML页面的时间，但是浏览器一般是一块接着一块地显示而不是直接显示完整的整个页面，让人感觉响应时间要少一些。 另外，典型的情况是，负载测试工具不会考虑浏览器的重绘时间。 因此， 在实际的性能测试中，我们将考虑以上描述的情形， 如果不能确信，可以在正常的响应时间上加一个固定值，如0.5秒。　　以下是一套众所周知的确定相应时间的标准: 　　?用户将不会注意到少于0.1秒的延迟 　　?少于1秒的延迟不会中断用户的正常思维， 但是一些延迟会被用户注意到 　　?延迟时间少于10秒，用户会继续等待响应 　　?延迟时间超过10秒后，用户将会放弃并开始其他操作　　这些阀值很有名并且一般不会改变，因为是关乎人类的感知特性的。 所以要根据这些规则来设置响应时间需求， 也需要适当调整以适应实际应用。例如，亚马逊公司() 的主页也遵循了以上规则，但是由于更偏重于风格上的一致，所以在响应时间上有一点损失。 　　乍一看，好像有两种不同的方式来确定相应时间需求： 　　?平均响应时间(Average response time )　　?绝对响应时间（Absolute response time）;即， 所有的响应时间必须低于某一阀值　　指定平均响应时间比较简单一些（straightforward），但是由于数据变化的干扰，这个需求往往难以实现。为什么取样中的20%的响应时间要比平均值高3倍以上呢？请注意，JMeter 计算平均响应时间与图形结果监视器中的标准偏差是一致的。 　　另一方面， 对绝对响应时间需求过于苛求是不实际的。 如果只有0。5%的取样不能通过测试该怎么办？如果再测一次，又会有很大的变化。 幸运的是， 使用置信区间（confidence interva）分析这种正规的统计方法可以顾及到取样变化的影响。 在继续进行前，让我们首先回顾一些基本的统计学知识。 　　中心极限定理（The central limit theorem）&　　中心极限定理表明如果总体的分布有一个平均值μ和标准偏差σ，那么对于一个十分大的n(&30)，其取样平均值的分布将接近于正态分布，其平均值μmean = μ ，标准偏差σmean = σ/√n。 注意取样平均值的分布是正态的，而取样自身的分布不必是正态的。也就是说如果多次运行测试脚本则测试结果的平均响应时间将会是正态的。 　　图 5 和图 6 分别展示了两个正态分布。 在这里横坐标是采样响应时间的均值， 总体的均值被调整到坐标的原点（shifted so the population mean is at the origin）。 图5 表明90%的时间里，采样均值位于±Zσ的区间里（percent of the time， the sampling means are within the interval ±Zσ，），这里的Z=1.645 和 σ 是标准偏差。 图 6 表明了99%的情况下的情形这时的Z=2.576。 在给定的概率下，如90%， 我们可以看到相应的Z呈现正态曲线，反之亦然。
　　Figure 5。 Z value for 90 percent&&
　　Figure 6。 Z value for 99 percent　　在相关资料中所列的是可提供正态曲线计算的一些网站。在这些网站，我们可以计算随意的相对区间内的概率(如，-1.5 & X & 1.5)或者在一个聚集的区域（cumulated area）内 ，(如， X & 1.5)。 也可以从下面的表中得到近似值。 　　表 1。 对应于给定的置信区间（confidence interval）的标准偏差范围（Standard deviation range）
　　表 2。 对应于给定的标准偏差范围（Standard deviation）的置信区间（confidence interval）
　　置信区间（Confidence interval）&　　置信区间（confidence interval）的定义是[取样平均值- Z*σ/√n， 取样平均值+ Z*σ/√n]。 例如， 如果置信区间（概率）是90%， 经查找可知Z 值是1。645， 于是置信区间就是 [取样平均值- 1。645*σ/√n， 取样平均值+ 1。645*σ/√n]， 这意味着在90%的时间里， 总体平均值（population mean）(是未知的) 会落入这个置信区间内。 也就是说， 我们的测试结果是十分接近的。 如果 σ（标准偏差） 更大一些， 置信区间也会更大，这就意味着置信区间的上限就会更可能会越过可以接受的范围，即σ 越大，结果越不可信。 　　响应时间需求（Response-time requirements ）&&&&　　现在我们把所有的信息都归结到响应时间需求上来。首先。必须要定义性能需求，如: %95概率的置信区间的平均响应时间的上限必须小于5秒。 当然，最好有相应的需求或场景。 　　在性能测试结束后，假设进分析得出结论是平均响应时间是4.5秒，标准偏差时4.9秒，样本数量是120个，然后就可以计算%95概率的置信区间了。 通过查表1，找到Z值是 1。95996。 于是置信区间就是 [4.5 C 1./√120， 4.5 + 1./√120]， 也就是 [3.62， 5.38]。 尽管看起来这个响应时间看起来很不错，但这个结果（因为超出了需求的要求，因而）是不可接受的。 实际上， 可以检验的是即使是对于80%概率的可信区间，这个测试结果也是不能接受的。正如你所看到的，使用了置信区间分析后，会得到一个十分精确的方法来估算测试质量。 　　在web应用中，为了测定某一场景的响应时间，我们一般要通过测试工具来发送多个访问请求，例如： 　　4.&登陆 　　5.&显示表单 　　6.&提交表单　　假设我们对请求3更感兴趣。为进行置信区间分析，我们需要的仅是请求3的所有样本的响应时间均值和标准偏差，而不是全部被统计的样本的。 　　在Jmeter的图表结果监听器中计算的却是全部请求的响应时间均值和标准偏差。 而Jmeter的聚合报告监听器计算的是独立的采样器的响应时间均值，可惜没有计算标准偏差。 总之， 仅仅指定响应时间均值是危险的， 因为不能反映出数据的变化。 即使响应时间均值是可以接受的，但是置信区间仅有75％，这个结果也不能令人信服。但是，使用置信区间分析还是会带来更多的确定性。 　　结论　　本文讨论了以下内容: 　　?详细讲解了Jmeter 线程组在加载负载时的特别设置 　　?使用Jmeter代理服务器(Proxy Server)元件自动建立测试脚本的指导方针，其重点在于模拟用户思考时间（user think time ）。　　?置信区间分析（Confidence interval analysis）， 一种我们可以用来更好地满足响应时间需求的统计分析方法　　通过使用本文提及的技术可以改善测试脚本的质量，更广泛地说，本文所讨论的内容属于是性能测试的一个工作流程的一部分， 是其中的一个较困难的部分。性能测试包括并不仅限于以下内容： 　　?编写性能测试需求　　?选择测试情景 　　?准备测试环境　　?编写测试脚本 　　?执行测试　　?回顾测试脚本和测试结果 　　?指出性能瓶颈 　　?书写测试报告　　此外， 性能测试结果，包括确定下来的瓶颈， 都需要反馈给开发团队或者架构师进行优化设计。 在这个过程中，并写测试脚本和回顾测试脚本是其中很重要的部分，要精心筹划和管理实施。凭借测试脚本指导和一个好的性能测试流程，你将会有更多的机会来在较重负载下优化软件性能。　　关于作者　　Chi-Chang Kung 是台湾Sun 公司的java系统架构师，也是IEEE 和ACM的成员。 　　相关资源 　　?JMeter: http://jakarta.apache.org/jmeter/index.html 　　?《中心极限理论以及经典推论》（"Central Limit Theorem and Classical Inference" ）Scott M。 Lynch (2005年2月):
　　?置信区间（Confidence intervals）:
　　?《java网站的性能分析》（Performance Analysis for
Websites）， Stacy Joines et al. (Addison-Wesley， 2002年9月; ISBN: ):
?《响应时间：三个重要的限制条件》("Response Times: The Three Important Limits") 引自《实用工程学》( Usability Engineering)， Jakob Nielsen (Morgan Kaufmann， 1994; ISBN ):
　　?一些提供了正态曲线计算功能的网站(Websites for normal curve calculation): 　　o&&&&&&&&http://www.psychstat.smsu.edu/introbook/normal.htm 　　o&&&&&&&&http://www.ecositebr.bio.br/curva_normal.htm 　　o&&&&&&&&　　?更多关于测试的文章，请参照JavaWorld's 标题索引的Testing 部分:
　　?关于JAVA开发工具，参见JavaWorld's 标题索引的Development Tools 部分:
【责编:yuan】
没有相关文章
?&[]?&[]?&[]?&[]?&[]?&[]?&[]?&[]?&[]?&[]
相关产品和培训
　友情推荐链接
　认证培训
　专题推荐
　?　?　?　?　?　?　?　?　?　?
　今日更新
?&?&?&?&?&?&?&?&?&?&
　社区讨论
　博客论点
　频道精选
　Java 频道导航您所在的位置： &
使用JMeter测试JSP应用程序性能
使用JMeter测试JSP应用程序性能
本文介绍使用JMeter测试JSP应用程序性能，以及介绍你想测试你的JSP应用程序性能,那么你可以使用JMeter,它是由Apache软件基金会开发的开放源代码的产品。
如果你想测试你的JSP应用程序性能,那么你可以使用JMeter,它是由Apache软件基金会开发的开放源代码的产品.JMeter允许你开发测试方案,用以测试可访问的HTTP,FTP和JDBC数据库服务器.JMeter可使用cookie和URL重写来处理Servlet验证,因此,在测试JSP应用程序时表现良好.它的下载地址为:http://jakarta.apache.org/jmeter
下面来看看JMeter,你可以写一个非常简单的JSP页面来使用JMeter进行测试,比如:test.jsp.为了测试该页面,我们首先生成包括5个线程的线程组,各循环100次.这样就会模拟5各浏览器的效果,每个浏览器运行测试方案100次.
运行jmeter.bat,就会显示出一个Java swing技术所构建的一个GUI窗口.右击左边树状结构的测试计划,选择添加-&线程组选项添加一个线程组,在线程数中填写5,即模拟5各浏览器;在Ramp-Up Period(in seconds)里填写5;在循环次数中填写100.
接着需要在线程组下生成一个HTTP请求并配置它来访问你的test.jsp页面.右击线程组,选择添加-&Sampler-&HTTP请求.在服务器名称或IP中填写你的主机名或IP,在这个例子中我写的是端口号请根据具体情况填写,我的是8080;协议填写HTTP,方法是G路径根据你的环境填写你的JSP页面的地址,我写的是/test/test.其他的值都默认.
然后添加一个报告.右击线程组,选择添加-&监听器-&聚合报告.当我们运行这个线程组的时候这里就会出现浏览测试页运行的最小,最大和平均响应时间等信息.如果你需要将报告的内容写入一个文件中,那么你可以在文件名那里填写要保存的文件路径及文件名,当然这是可选的.
终于到了最后的步骤,点击运行菜单-&启动来运行测试方案.运行测试可能会花费一些时间.测试运行时,你可以在聚合报告窗口查看结果.
JSP应用程序不仅可以生成聚合报告,还可以生成一些其他的报告,比如Spline Visualizer(样条曲线可视化器),设置和聚合报告差不多.
【编辑推荐】
【责任编辑： TEL：（010）】
关于&&的更多文章
AngularJS是很多Web开发人员在打造单页面应用程序时的首选创建方
随着云计算、物联网、大数据、移动互联网的大发展，你应该知道这些。
讲师： 38人学习过讲师： 1479人学习过讲师： 19人学习过
Web应用程序框架领域涌现出了一股创新热潮，这可能让
新手程序员你们好！你是否做好了进入编程世界的准备呢
TIOBE编程语言排行榜Java以4.5%的差距遥遥领先于第二
本书全面介绍了Windows Server 2003 R2中最常用的各种服务，包括域名服务、动态IP地址服务、Windows名称服务、活动目录服务、Web
51CTO旗下网站温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
通过运行，可以看到结果树里面的结果，重点要看的是响应数据里面的内容。输出内容时可以配置的，正常是要配置的是&
通过上图，会发现，配置了Save Success, Save Time Stamp, Save Label, Save Elapsed time。这里要注意的是__P函数的应用。前面是两个下划线（这个是容易出错的地方）。前面写变量的名字，通过$符号取出变量值，例如IP& ${__P(ip,172.17.16.136)}，前面的一个ip是参数ip，后面的172.17.16.136是默认的IP值。这样当在命令行输入/usr/local/jakarta-jmeter-2.4/bin/jmeter -n -t/home/tony/Jmeter/script/work.jsp.jmx -Jip=172.17.16.136 -Jport=8080 -JlogPath=/home/tony/Jmeter/log/log.jtl
就可以在命令行执行操作。
说到此，就不得不提到crontab这个job了，可以很好的执行定义的行为。crontab中有两个比较有用的命令操作，例如crontab –r移除所有的job，crontab –l列出了当前的job，
crontab –e修改job，但是此修改并不会存入到文件中。我这里的crontab.sh文件夹中的内容为：*/5 * * * * /usr/local/jakarta-jmeter-2.4/bin/jmeter -n -t/home/tony/Jmeter/script/work.jsp.jmx -Jip=172.17.16.136 -Jport=8080 -JlogPath=/home/tony/Jmeter/log/log.jtl
上面这条命令实现了每五分钟执行了一次此操作。要执行crontab crontab.sh注意，这里是相当于shell的文件，所有要赋予这个文件可执行的权限，chmod u+x crontab.sh就可以实现，至此，就算完成了吧，恭喜你，入门了。
阅读(1893)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
loftPermalink:'',
id:'fks_',
blogTitle:'Linux下Jmeter配置和使用，并使用crontab执行job',
blogAbstract:'
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}新手园地& & & 硬件问题Linux系统管理Linux网络问题Linux环境编程Linux桌面系统国产LinuxBSD& & & BSD文档中心AIX& & & 新手入门& & & AIX文档中心& & & 资源下载& & & Power高级应用& & & IBM存储AS400Solaris& & & Solaris文档中心HP-UX& & & HP文档中心SCO UNIX& & & SCO文档中心互操作专区IRIXTru64 UNIXMac OS X门户网站运维集群和高可用服务器应用监控和防护虚拟化技术架构设计行业应用和管理服务器及硬件技术& & & 服务器资源下载云计算& & & 云计算文档中心& & & 云计算业界& & & 云计算资源下载存储备份& & & 存储文档中心& & & 存储业界& & & 存储资源下载& & & Symantec技术交流区安全技术网络技术& & & 网络技术文档中心C/C++& & & GUI编程& & & Functional编程内核源码& & & 内核问题移动开发& & & 移动开发技术资料ShellPerlJava& & & Java文档中心PHP& & & php文档中心Python& & & Python文档中心RubyCPU与编译器嵌入式开发驱动开发Web开发VoIP开发技术MySQL& & & MySQL文档中心SybaseOraclePostgreSQLDB2Informix数据仓库与数据挖掘NoSQL技术IT业界新闻与评论IT职业生涯& & & 猎头招聘IT图书与评论& & & CU技术图书大系& & & Linux书友会二手交易下载共享Linux文档专区IT培训与认证& & & 培训交流& & & 认证培训清茶斋投资理财运动地带快乐数码摄影& & & 摄影器材& & & 摄影比赛专区IT爱车族旅游天下站务交流版主会议室博客SNS站务交流区CU活动专区& & & Power活动专区& & & 拍卖交流区频道交流区
丰衣足食, 积分 662, 距离下一级还需 338 积分
论坛徽章:0
使用 JMeter 完成常用的压力测试
胡 键 (), 西安交通大学硕士
　本文介绍了 JMeter 相关的基本概念。并以 JMeter 为例，介绍了使用它来完成最常用的三种类型服务器，即 Web 服务器、数据库服务器和消息中间件，压力测试的方法、步骤以及注意事项。
　讲到测试，人们脑海中首先浮现的就是针对软件正确性的测试，即常说的功能测试。但是软件仅仅只是功能正确是不够的。在实际开发中，还有其它的非功能因素也起着决定性的因素，例如软件的响应速度。影响软件响应速度的因素有很多，有些是因为算法不够高效；还有些可能受用户并发数的影响。
在众多类型的软件测试中，压力测试正是以软件响应速度为测试目标，尤其是针对在较短时间内大量并发用户的访问时，软件的抗压能力。本文以 JMeter 为例，介绍了如何使用它来完成常用的压力测试：Web 测试、数据库测试和 JMS 测试。
JMeter 最早是为了测试 Tomcat 的前身 JServ 的执行效率而诞生的。到目前为止，它的最新版本是2.1.1，它的测试能力也不再仅仅只局限于对于Web服务器的测试，而是涵盖了数据库、JMS、Web Service、LDAP等多种对象的测试能力。在最新的 2.1.1 中，它还提供了对于 JUNIT 的测试。
JMeter 的安装非常简单，从官方网站上下载，解压之后即可使用。运行命令在%JMETER_HOME%/bin 下，对于 Windows 用户来说，命令是 jmeter.bat。运行前请检查JMeter 的文档，查看是否具备相关的运行条件。对于最新版（即2.1.1），需要JDK的版本要求是JDK 1.4。
JMeter 的主要测试组件总结如下：
1. 测试计划是使用 JMeter 进行测试的起点，它是其它 JMeter 测试元件的容器。
2. 线程组代表一定数量的并发用户，它可以用来模拟并发用户发送请求。实际的请求内容在Sampler中定义，它被线程组包含。
3. 监听器负责收集测试结果，同时也被告知了结果显示的方式。
4. 逻辑控制器可以自定义JMeter发送请求的行为逻辑，它与Sampler结合使用可以模拟复杂的请求序列。
5. 断言可以用来判断请求响应的结果是否如用户所期望的。它可以用来隔离问题域，即在确保功能正确的前提下执行压力测试。这个限制对于有效的测试是非常有用的。
6. 配置元件维护Sampler需要的配置信息，并根据实际的需要会修改请求的内容。
7. 前置处理器和后置处理器负责在生成请求之前和之后完成工作。前置处理器常常用来修改请求的设置，后置处理器则常常用来处理响应的数据。
8. 定时器负责定义请求之间的延迟间隔。
JMeter的使用非常的容易，在
上的文章 Using JMeter 提供了一个非常好的入门。
　常用测试
压力测试不同于功能测试，软件的正确性并不是它的测试重点。它所看重的是软件的执行效率，尤其是短时间内访问用户数爆炸性增长时软件的响应速度，压力测试往往是在功能测试之后进行的。在实际的开发过程中，软件潜在的效率瓶颈一般都是那些可能有多个用户同时访问的节点。
就目前 Java EE 的平台下开发的软件来说，这种节点通常可能是：Web 服务器、数据库服务器和 JMS 服务器。它们都是请求主要发生的地点，请求频率较其它的节点要高，而且处于请求序列的关键路径之上。如果它们效率无法提高的话，对于整个软件的效率有致命的影响。而且在这些节点上一般都会发生较大规模的数据交换，有时其中还包含有业务逻辑处理，它们正是在进行压力测试时首先需要考虑的。
本文以这三种节点为例，介绍如何使用 JMeter 来完成针对于它们的压力测试。
Web 服务器
对于大多数的项目来说，并不会自行开发一个Web服务器，因此Web服务器压力测试的对象实际就是--发布到Web服务器中的软件。最简单的Web测试计划只需要三个 JMeter 的测试元件，如下图：
在线程组中定义线程数、产生线程发生的时间和测试循环次数。
在http请求中定义服务器、端口、协议和方法、请求路径等。
表格监听器负责收集和显示结果。
这种设置对于包含了安全机制的 web 应用是不够的，典型的 web 应用一般都会：
　1. 有一个登录页，它是整个应用的入口。当用户登录之后，应用会将用户相关的安全信息放到 session 中。
　2. 有一个 filter，它拦截请求，检查每个请求相关的 session 中是否包含有用户安全信息。
　如果没有，那么请求被重定向到登录页，要求用户提供安全信息。
　在这种配置下应用上面的测试计划，那么除了登录页之外的其它请求都将因为缺少用户安全信息，而使请求实际定位到登录页。如果不加断言，那么在监听器看来所有的请求都是成功。而实际上，这些请求最终都没有到达它们应该去的地方。显然，这种测试结果不是我们所期望的。
　为了成功的测试，至少有2种方法：
方法一，去掉程序的安全设置，如filter，使得不需要用户安全信息也能访问受限内容；
方法二，不修改程序，使用JMeter提供的&Http URL重写修饰符&或&Http Cookie管理器&。 　对于第一种方法，有其局限性：
需要修改程序配置，如去掉web.xml中关于安全filter的设置。需要维护多个版本的web.xml，如压力测试和功能测试分别各自的web.xml，增加了维护成本，而且有可能会在测试之后忘记将web.xml修改回来。
对于一些需要用户安全信息的页面无能为力，如某些业务审计操作需要用户安全信息来记录。因为缺少这样的信息，注定了测试的失败。如果解决为了这个问题进一步的修改程序，那么因为存在多个版本的程序，那么其维护难度将大大增加。 　虽然，第二种方法配置难度增加了，但是它不用修改程序。而且还可将测试计划保存成文件，以便重复使用。因此，选用第二种方法是较为理想的做法。下面以一个简化的例子说明使用方法二的配置步骤。
1. 例子由以下几个文件组成：
AuthorizenFilter.java，过滤器负责检验session中是否存在用户信息。如果没有，那么就转向到 login.jsp。它的主要方法 doFilter 内容如下：
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
throws IOException, ServletException {
HttpServletRequest req = (HttpServletRequest)
HttpServletResponse res = (HttpServletResponse)
HttpSession session= req.getSession();
User user = (User)session.getAttribute(&user&);
if(null == user){
String uri= req.getRequestURI();
//如果请求页是登录页，不转向
if( uri.equalsIgnoreCase(&/gWeb/login.jsp&)){
chain.doFilter(request, response);
res.sendRedirect(&/gWeb/login.jsp&);
chain.doFilter(request, response);
User.java，用户类负责记录用户的信息。为了简化，这里的登录操作只允许指定用户名和密码。主要内容如下：
public class User {
public User(String user, String pwd) {
this.user =
this.pwd =
public boolean login(){
return user.equals(&foxgem&) && pwd.equals(&&);
public String getUser() {
public void setUser(String user) {
this.user =
Login.jsp 和welcome.jsp。其中 login.jsp 负责生成 User 对象，并调用 User 的login。当 login 返回为 true 时转向到 welcome.jsp。其验证部分的代码：
web.xml，配置 filter 拦截所有访问 JSP 页面的请求：
authorizen
org.foxgem.jmeter.AuthorizenFilter
authorizen
2. 创建如下结构的Web测试计划：
其中主要测试元件说明如下：
http请求默认值负责记录请求的默认值，如服务器、协议、端口等。
第一个http请求，请求login.jsp，并附加验证所需要的参数（user=foxgem，pwd=，Submit=Submit）；其包含的响应断言验证url中包含&welcome.jsp&，这一点可以从程序中反应。
第二个http请求，请求是welcome.jsp；其包含的响应断言验证响应文本中包含&foxgem&，它是welcome.jsp页面逻辑的一部分。
http cookie管理器负责管理整个测试过程中使用的cookie，它不需要设置任何属性。
循环控制器设置发送第二个请求的循环次数，表格监听器负责收集和显示第二个请求的测试结果。 　　　　　　　　　　　　　　
启动测试计划之后，执行的顺序是：首先，第一个请求登录页进行登录；成功登录之后，使用循环控制器执行第二个请求。请求welcome.jsp时，响应断言用来验证是否确实是welocme.jsp来处理请求，而不是因为其它页。在这个测试计划中需要注意的是http cookie管理器。正是由于它的作用，使得第二个请求能顺利的发送到welcome.jsp进行处理，而不是因为缺少用户安全信息转发到login.jsp。
在这个例子中，我们并没有在程序中使用cookie（使用的是session），那么http cookie管理器怎么会起作用呢？这是因为在servlet/jsp规范中对于session的状态跟踪有2种方式：
使用cookie，保留和传递sessionid。它不要求程序对于url有什么特殊的处理，但是要求浏览器允许cookie。在这个例子中，就是这种情形。
使用url重写，每次显式的在浏览器和服务器之间传递sessionid。它要求程序对url进行编码，对浏览器没有要求。 　对于第二种情形，可以使用JMeter前置管理器中的http url重写修饰符来完成。对于Tomcat，Session参数是jsessionid，路径扩展使用&；&。使用url编码时需要注意，必须将浏览器的cookie功能关闭。因为url编码函数，如encodeURL，会判断是否需要将sessionid编码到url中。当浏览器允许cookie时，就不会进行编码。
如果cookie而不是session来保存用户安全信息，那么直接使用http cookie管理器就行了。此时，需要将使用的cookie参数和值直接写到管理器中，由它负责管理。对于其它的cookie使用，也是如此操作。
登录问题解决之后，对于 Web 服务器的测试就没什么难点了。剩下的就是根据实际需要，灵活运用相关的测试组件搭建编写的测试计划。（当然，对于安全问题还有其它的使用情景。在使用时需要明确：JMeter 是否支持，如果支持使用哪种测试组件解决。）
数据库服务器
数据库服务器在大多数企业项目中是不可缺少的，对于它进行压力测试是为了找出：数据库对象是否可以有效地承受来自多个用户的访问。这些对象主要是：索引、触发器、存储过程和锁。通过对于SQL语句和存储过程的测试，JMeter 可以间接的反应数据库对象是否需要优化。
JMeter 使用 JDBC 发送请求，完成对于数据库的测试。一个数据库测试计划，建立如下结构即可：
JDBC连接配置，负责配置数据库连接相关的信息。如：数据库url、数据库驱动类名、用户名和密码等等。在这些配置中，&绑定到池的变量名&（Variable Name Bound to Pool）是一个非常重要的属性，这个属性会在JDBC请求中被引用。通过它， JDBC请求和JDBC连接配置建立关联。（测试前，请将所需要的数据库驱动放到JMeter的classpath中）。
JDBC请求，负责发送请求进行测试。
图形结果，收集显示测试结果。 　在实际的项目中，至少有2种类型的JDBC请求需要关注：select语句和存储过程。前者反应了select语句是否高效，以及表的索引等是否需要优化；后者则是反应存储过程的算法是否高效。它们如果效率低下，必然会带来响应上的不尽如人意。对于这两种请求，JDBC请求的配置略有区别：
Select语句
如果对于Oracle，如果测试的是函数，那么也可以使用select语句来进行配置，此时可以使用：select 函数(入参) from dual形式的语句来测试，其中dual是oracle的关键字，表示哑表。对于其它厂商的数据库产品，请查找手册。
MOM 作为消息数据交换的平台，也是影响应用执行效率的潜在环节。在 Java 程序中，是通过 JMS 与 MOM 进行交互的。作为 Java 实现的压力测试工具，JMeter 也能使用 JMS 对应用的消息交换和相关的数据处理能力进行测试。这一点应该不难理解，因为在整个测试过程中，JMeter 测试的重点应该是消息的产生者和消费者的本身能力，而不是 MOM本身。
根据 JMS 规范，消息交换有2种方式：发布/订阅和点对点。JMeter针对这两种情形，分别提供了不同的Sampler进行支持。以下MOM我们使用ActiveMQ 3.2.1，分别描述这两种消息交换方式是如何使用 JMeter 进行测试。
1. 测试前的准备（两种情况都适用）
JMeter 虽然能使用 JMS 对 MOM 进行测试，但是它本身并没有提供JMS需要使用的包。因此，在测试之前需要将这些包复制到 %JMETER_HOME%/lib 下。对于 ActiveMQ 来说，就是复制 %ACTIVEMQ_HOME%/lib。%ACTIVEMQ_HOME%/optional 是可选包，可根据实际情况来考虑是否复制。
JMeter 在测试时使用了 JNDI，为了提供 JNDI 提供者的信息，需要提供 jndi.properties。同时需要将 jndi.properties 放到 JMeter 的 classpath 中，建议将它与 bin下的 ApacheJMeter.jar 打包在一起。对于 ActiveMQ，jndi.properties 的示例内容如下：
java.naming.factory.initial = org.activemq.jndi.ActiveMQInitialContextFactory
java.naming.provider.url = tcp://localhost:61616
#指定connectionFactory的jndi名字，多个名字之间可以逗号分隔。
#以下为例：
#对于topic，使用(TopicConnectionFactory)context.lookup(&connectionFactry&)
#对于queue，(QueueConnectionFactory)context.lookup(&connectionFactory&)
connectionFactoryNames = connectionFactory
#注册queue，格式：
#queue.[jndiName] = [physicalName]
#使用时：(Queue)context.lookup(&jndiName&)，此处是MyQueue
queue.MyQueue = example.MyQueue
#注册topic，格式：
# topic.[jndiName] = [physicalName]
#使用时：(Topic)context.lookup(&jndiName&)，此处是MyTopic
topic.MyTopic = example.MyTopic
2. 发布/订阅
在实际测试时，发布者和订阅者并不是需要同时出现的。例如，有时我们可能想测试单位时间内消息发布者的消息产生量，此时就不需要消息发布者，只需要订阅者就可以了。本例为了说明这两种Sampler的使用，因此建立如下的测试计划：
　其中JMS Publisher和JMS Subscriber的属性：选择&使用jndi.properties&，连接工厂是connectionFactory，主题是MyTopic，其它使用默认配置。对于JMS Publisher，还需提供测试用的文本消息。
启动ActiveMQ，运行测试计划。如果配置正确，那么与ActiveMQ成功连接之后，在JMeter的后台会打印出相关信息。在测试过程中，JMeter 后台打印可能会出现java.lang.InterruptedException 信息，这个是正常现象，不会影响测试过程和结果。这一点可以从 bin 下的 jmeter.log 看出。
对于点对点，JMeter只提供了一种Sampler：JMS Point-to-Point。在例子中，建立如下图的测试计划：
其中：Communication style是Request Only。对于另一种风格：Request Response，会验证收到消息的JMS Header中的JMSCorrelationID，以判断是否是对请求消息的响应。
本文介绍了如何使用JMeter完成最常用的三种类型服务器的压力测试，这三种类型的压力测试涵盖了很大一部分的使用情形，然而需要记住的是工具毕竟是工具。效果好不好，关键还是在于使用的人。而且，对于压力测试，测试计划的好坏是关键。针对不同的情况，分析后有针对的进行测试，比起拿枪乱打、无的放矢显然要高效得多。
本文来自ChinaUnix博客，如果查看原文请点：
&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp