【整理】JMeter技巧集锦分析（一）
引用
申明：本文结合网络，书本和自己的理解而成，在此申明文章引用来源。
来源：http://www.ltesting.net/ceshi/open/kyxncsgj/jmeter/2007/0622/60945.html
来源：http://www.ltesting.net/ceshi/open/kyxncsgj/jmeter/2007/0622/60945.html
目录：
- 一、确定一个线程组的ramp-up period （Determine）
- 二、用户思考时间（User think time），定时器
- 三、指定响应时间需求并校验结果
- 四、补充：实际中应用
- 五、公式
网上看到一篇文章，名为《JMeter技巧集锦》，其中提到的测试技巧都比较实用，所以引用到此。在这里添加一些自己的理解，下面用红色字体表示。本篇文章也适合其他性能测试工具分析。以下：
JMeter 是一个流行的用于负载测试的开源工具， 具有许多有用的功能元件，如线程组（thread group）， 定时器（timer）， 和HTTP 取样 (sampler) 元件。 本文是对JMeter 用户手册的补充，而且提供了关于使用Jmeter的一些模拟元件开发质量测试脚本的指导。
本文同时也讨论了一项重要的内容：在指定了精确的响应时间要求后，如何来校验测试结果，特别是在采用了置信区间分析这种严格的统计方式的情况下应如何操作。请注意，我假定本文的读者们了解关于Jmeter的基础知识，本文的例子基于Jmeter2。0。3版。
一、确定一个线程组的ramp-up period （Determine）
Jmeter脚本的第一个要素是线程组（Thread Group），因此首先让我们来回顾一下。 正如图一所示，线程组需要设置以下参数：
·线程数量。
·ramp-up period。
·运行测试的次数。
·启动时间:立即或者预定的时间，如果是后者，线程组所包含的元素也要指定这个起止时间。
图1 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 也是不恰当的，因为将会降低访问峰值的负载，换句话说，在一些线程还未启动时，初期启动的部分线程可能已经结束了。
图2 Aggregate Report
那么，如何检验ramp-up period I太小了或者太大了呢？
首先，推测一下平均点击率并用总线程除点击率来计算初始的ramp-up period。 例如，假设线程数为100， 估计的点击率为每秒10次， 那么估计的理想ramp-up period 就是 100/10 = 10 秒。 那么，应怎样来提出一个合理的估算点击率呢？没有什么好办法，必须通过运行一次测试脚本来获得。
其次， 在测试计划（test plan）中增加一个聚合报告监听器，如图所示，其中包含了所有独立的访问请求（一个samplers）的平均点击率。 第一次取样的点击率（如http请求）与ramp-up period 和线程数量密切相关。通过调整ramp-up period 可以使首次取样的点击率接近平均取样的点击率。
第三，查验一下Jmeter日志(文件位置：JMeter_Home_Directory/bin) 的最后一个线程开始时第一个线程是否真正结束了，二者的时间差是否正常。
总之，是否能确定一个适当的ramp-up time 取决于以下两条规则:
- 第一个取样器的点击率（hit rate）是否接近其他取样器的平均值，从而能否避免ramp-up period 过小。
- 在最后一个线程启动时，第一个线程是否在真正结束了，最好二者的时间要尽可能的长，以避免ramp-up period过大。
有时，这两条规则的结论会互相冲突。 这就意味着无法找到同时满足两条规则的合适的ramp-up period。 糟糕的测试计划通常会导致这些问题，这是因为在这样的测试计划里，取样器将不能充分地采集数据，可能因为测试计划执行时间太短并且线程会很快的运行结束。
注意：ramp-up period 好像只能输入整数，输入小数字会发现 Log 文件记录各线程在同一时间启动。
二、用户思考时间（User think time），定时器
在负载测试中需要考虑的的一个重要要素是思考时间（think time）， 也就是在两次成功的访问请求之间的暂停时间。 有多种情形挥发导致延迟的发生： 用户需要时间阅读文字内容，或者填表， 或者查找正确的链接等。 未认真考虑思考时间经常会导致测试结果的失真。例如，估计数值不恰当，也就是被测系统可以支持的最多用户量（并发用户）看起来好像要少一些等。
Jmeter提供了一整套的计时器（timer）来模拟思考时间（think time）， 但是仍旧存在一个问题： 如何确定适当的思考时间呢？幸运的是， JMeter 提供了一个不错的答案：使用 JMeter HTTP 代理服务器（Proxy Server）元件。
图3 Gaussian Random Timer
在代理服务器元件中可以增加一个定时器子元件（配置元件），用于告知Jmeter来在其生成的HTTP请求中自动的增加一个定时器。Jmeter会自动把实际的延迟时间存储为一个被命名为T的Jmeter变量，因此，如果在代理服务器元件里使用了高斯随机定时器，就应该在其中的固定延迟偏移（Constant Delay Offset）设置项里添上${T}（用于自动引用纪录的延迟时间），如图4所示。这是另一个节省时间的便利特性。
定时器将会使相应的的取样器被延迟。 延时的规则是，在上一个访问请求被响应并延时了指定的时间后，下一个被定时器影响的取样访问请求才会被发送出去。 因此， 你必须手工删除第一个取样器中自动生成的定时器，因为第一个取样器不需要定时器。
三、指定响应时间需求并校验结果
尽管本节内容与Jmeter不是直接相关，但是Jmeter仍旧是指定响应时间需求和校验测试结果这两个负载测试评价任务互相联系的纽带。
在web应用的环境里，响应时间指的是从提交访问请求到等到HTML结果所耗费的时间。从技术的角度看，响应时间也应包括浏览器重绘HTML页面的时间，但是浏览器一般是一块接着一块地显示而不是直接显示完整的整个页面，让人感觉响应时间要少一些。 另外，典型的情况是，负载测试工具不会考虑浏览器的重绘时间。 因此， 在实际的性能测试中，我们将考虑以上描述的情形， 如果不能确信，可以在正常的响应时间上加一个固定值，如0.5秒。
以下是一套众所周知的确定相应时间的标准:
- 用户将不会注意到少于0.1秒的延迟
- 少于1秒的延迟不会中断用户的正常思维， 但是一些延迟会被用户注意到
- 延迟时间少于10秒，用户会继续等待响应
- 延迟时间超过10秒后，用户将会放弃并开始其他操作
乍一看，好像有两种不同的方式来确定相应时间需求：
- 平均响应时间(Average response time)
- 绝对响应时间（Absolute response time）;即，所有的响应时间必须低于某一阀值
指定平均响应时间比较简单一些（straightforward），但是由于数据变化的干扰，这个需求往往难以实现。为什么取样中的20%的响应时间要比平均值高3倍以上呢？请注意，JMeter 计算平均响应时间与图形结果监视器中的标准偏差是一致的。
中心极限定理（The central limit theorem）
中心极限定理表明如果总体的分布有一个平均值μ和标准偏差σ，那么对于一个十分大的n(>30)，其取样平均值的分布将接近于正态分布，其平均值μmean = μ ，标准偏差σmean = σ/√n。
注意取样平均值的分布是正态的，而取样自身的分布不必是正态的。也就是说如果多次运行测试脚本则测试结果的平均响应时间将会是正态的。
图5 Z value for 90 percent
图6 Z value for 99 percent
图4 和图5 分别展示了两个正态分布。 在这里横坐标是采样响应时间的均值， 总体的均值被调整到坐标的原点（shifted so the population mean is at the origin）。 图4 表明90%的时间里，采样均值位于±Zσ的区间里（percent of the time， the sampling means are within the interval ±Zσ，），这里的Z=1.645 和 σ 是标准偏差。 图5 表明了99%的情况下的情形这时的Z=2.576。 在给定的概率下，如90%， 我们可以看到相应的Z呈现正态曲线，反之亦然。
另一方面， 对绝对响应时间需求过于苛求是不实际的。 如果只有0.5%的取样不能通过测试该怎么办？如果再测一次，又会有很大的变化。 幸运的是， 使用置信区间（confidence interva）分析这种正规的统计方法可以顾及到取样变化的影响。
在继续进行前，让我们首先回顾一些基本的统计学知识。
在相关资料中所列的是可提供正态曲线计算的一些网站。在这些网站，我们可以计算随意的相对区间内的概率(如，-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%概率的可信区间，这个测试结果也是不能接受的。正如你所看到的，使用了置信区间分析后，会得到一个十分精确的方法来估算测试质量。
四、补充：实际中应用
表1 和表2 提供了Z值和置信区间（概率）的直观对应情况，而一般的Z值表仅提供Z值和正态分布对应情况，那么如何根据置信区间（概率）查找计算Z值，以及如何根据Z值查找计算置信区间（概率）呢？
例1：已知置信区间（概率）0.95，计算Z值。
左右每个正太分布 = (1-0.95)/2 = 0.025
查Z表 --> Z = 1.96
例2：已知Z值1.96，计算置信区间（概率）。
查Z表 --> 左右每个正太分布 = 0.025
置信区间（概率） = 1-2*0.025 = 0.95
例3：已知需求中最大响应时间T(req)以及实际平均响应时间T(mean)和标准偏差σ，求实际最大响应时间是否满足需求。（16个采样为例）。
实际最大响应时间 T(max) = T(mean) + Z * σ / √16
95%采样： T(max) = T(mean) + 1.96 * σ / 4
90%采样： T(max) = T(mean) + 1.64 * σ / 4
return T(max) < T(req) ? true : false
例4：已知需求中最大响应时间T(req)以及实际平均响应时间T(mean)和标准偏差σ，求符合响应时间的采样概率。（16个采样为例）。
解： 设采样概率为x。
T(req) = T(mean) + (1-x)/2 * σ / 4
x = 1 - [(T(req) - T(mean)) * 8 / σ]
五、公式
Z = (1-置信概率)/2 --> 查Z表
取样品均误差：Z*σ/√n
置信下限：取样平均值 - Z*σ/√n
置信上限：取样平均值 + Z*σ/√n