jmeter学习笔记（小tips）

聚合报告说明：

一、throughput：吞吐量，默认状况下表示每秒完成的请求数( Request per Second )

二、KB/Sec:每秒从服务器端接收到的数据量

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)， 或Aclearcase/" target="_blank" >cceptLanguage (e。g。， zh-tw，en-us;q=0。7，zh-cn;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，包括包含图像和JavaScripts脚本的页面。固然 也能够尝试一下默认值“不对样本分组”（"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秒后，用户将会放弃并开始其余操做

　　这些阀值颇有名而且通常不会改变，由于是关乎人类的感知特性的。 因此要根据这些规则来设置响应时间需求， 也须要适当调整以适应实际应用。例如，亚马逊公司(Amazon.com) 的主页也遵循了以上规则，可是因为更偏重于风格上的一致，因此在响应时间上有一点损失。 

　　乍一看，好像有两种不一样的方式来肯定相应时间需求： 
　　·平均响应时间(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 – 1.95996*4.9/√120， 4.5 + 1.95996*4.9/√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月):http://www.princeton.edu/~slynch/clt_inference.pdf 

　　·置信区间（Confidence intervals）: http://people.hofstra.edu/faculty/Stefan_Waner/RealWorld/finitetopic1/confint.html 

　　·《java网站的性能分析》（Performance Analysis for Java Websites）， Stacy Joines et al. (Addison-Wesley， 2002年9月; ISBN: 0201844540): http://www.amazon.com/exec/obidos/ASIN/0201844540/javaworld ·《响应时间：三个重要的限制条件》("Response Times: The Three Important Limits") 引自《实用工程学》( Usability Engineering)， Jakob Nielsen (Morgan Kaufmann， 1994; ISBN 0125184069): http://www.useit.com/papers/responsetime.html 　　·一些提供了正态曲线计算功能的网站(Websites for normal curve calculation): 　　o        http://www.psychstat.smsu.edu/introbook/normal.htm 　　o        http://www.ecositebr.bio.br/curva_normal.htm 　　o        http://statistik.wu-wien.ac.at/mathstat/hatz/vo/applets/probCalc/normal_z_p.html　　·更多关于测试的文章，请参照JavaWorld's 标题索引的Testing 部分: http://www.javaworld.com/channel_content/jw-testing-index.shtml 　　·关于JAVA开发工具，参见JavaWorld's 标题索引的Development Tools 部分: http://www.javaworld.com/channel_content/jw-tools-index.shtml