6、JMETER

最近的一个项目刚刚开发完，因为不是专业测试人员，所以记录下测试过程以备时间长忘记了。

一、JMeter的安装（Linux）
1. 下载JMeter：这个就不细说了，直接去(http://jmeter.apache.org/download_jmeter.cgi)下载。
2. 解压：tar -zxvf apache-jmeter-2.9.tgz
3. 执行：sh jmeter.sh。
如果提示（No X11 DISPLAY variable was set, but this program performed an operation which requires it.）
恭喜你，你的JMeter图形界面不能启动，这里需要用命令行执行了。
具体的执行方法后面会说，首先需要录制测试脚本。 比较方便的是在Win下面JMeter的图形界面中录制，或者用Badboy录制。

二、JMeter脚本录制 
   1. 创建组
a. Number of Threads(users)：通过多个线程模拟多个用户
b. Ramp-Up period(in seconds)：用于告知JMeter 要在多长时间内建立全部的线程。默认值是0。如果未指定ramp-up period ，也就是说ramp-up period 为零， JMeter 将立即建立所有线程，假设ramp-up period 设置成T 秒， 全部线程数设置成N个， JMeter 将每隔T/N秒建立一个线程。
ramp-up period设置容易出现的问题：

a. 如果设置成零，Jmeter将会在测试的开始就建立全部线程并立即发送访问请求， 这样一来就很容易使服务器饱和，更重要的是会隐性地增加了负载，这就意味着服务器将可能过载，不是因为平均访问率高而是因为所有线程的第一次并发访问而引起的不正常的初始访问峰值。这种异常不是我们需要的，因此，确定一个合理的ramp-up period 的规则就是让初始点击率接近平均点击率。当然，也许需要运行一些测试来确定合理访问量。

如果要使用大量线程，ramp-up period 一般不要设置成零。

b.  如果ramp-up period 过大也是不恰当的，因为将会降低访问峰值的负载，换句话说，在一些线程还未启动时，初期启动的部分线程可能已经结束了。

c. 合理的ramp-up period，首先推测一下平均点击率并用总线程除点击率来计算初始的ramp-up period。

    例如，假设线程数为100， 估计的点击率为每秒10次， 那么估计的理想ramp-up period 就是 100/10 = 10 秒。

2. 创建循环控制器 
在这里用于生成可变参数。
a. Loop Count：每个线程执行的次数
当前总样本数=Loop Count(Loop Controler)*Number of Threads*Loop Count(group)=2*100*500

 3. 定义可变参数
a. Filename：参数文件名
b. Variable Names：变量名与下面的自定义变量相对应
c. Delimiter：参数文件中的参数分隔符
注意：理论上文件中的参数数量不应该小于Loop Count*Number of Threads

4. 定义请求参数

5. 执行脚本
将脚本文件（.jmx）和参数文件（.csv）上传到服务器，如果未特殊指定参数文件的路径，将二个文件放在同一个路径下即可。
a. 命令为：sh jmeter.sh -n -t examples/41search_1.jmx -l examples/search_1_100T.jtl。
其它命令参数可查看帮助。

6. 查看结果
将生成的结果文件（search_1_100T.jtl）导出到本的，用JMeter打开查看
a. 聚合报告：具体说明见下篇

 b. 图形报告：具体说明见下篇
注意：这张图口味稍微有点重，密集恐惧症者慎入;-)

c. 树形报告：具体说明见下篇

 

 

 

 

 

 

一个每天1000万PV的网站需要什么样的性能去支撑呢？

 

继续上一篇，下面我们就来计算一下，前面我们已经搞到了一票数据，但是这些数据的意义还没有说。技术是为业务服务的，下面就来说说怎么让些数据变得有意义。

一、聚合报告
初识聚合报告是不是有些眼熟，是的你没看错，他跟Apache AB的结果是类似的，事实上LoadRunner也会有一票这样类似的数据。
下面分别说下各个数据的意义，其中标成红色的是需要特别关注的。

   1. #Samples：样本数，如果你看过上一篇，这个就是前面我们那个公式算出来的结果
（Loop Count(Loop Controler)*Number of Threads*Loop Count(group)）

   2. Average：平均响应时间。
 3. Median：中位数，50%用户响应时间。
 4. %90 Line：90%用户响应时间。
 5. Min：最小响应时间。
6. Max：最大响应时间。

 

   7. Error%：本次测试中出现错误的请求的数量/请求的总数

   8. Throughput：吞吐量，表示每秒完成的请求数。

   9. KB/Sec：每秒从服务器端接收到的数据量（只是接收）。

下面说说几个重点参数：
1.为什么说%90 Line重要呢？

举个栗子：姚明与郭敬明平均身高约1.84米能说明什么？如果这个例子不够形象再想想我大天朝的平均工资。所以平均不代表公平，因为总有那么一小撮人会极大的影响平均值，而大多数人是被平均的。

通过JMeter官网我们能发现对这个参数的定义（http://jmeter.apache.org/usermanual/glossary.html）：

90% Line (90 th Percentile) is the value below which 90% of the samples fall. The remaining samples too at least as long as the value. This is a standard statistical measure. See, for example: Percentile entry at Wikipedia.

貌似这段话说的不明不白，但他给我提示了一个重要的词Percentile，于是我们继续跟进，原来这是一个统计术语。维基上有详细说明，并有公式：n=(100/P)*N+1/2

其中n=排序位；P=待排序值；N=总的排序值数量

这块说的有点绕，看维基上的例子会比较清晰（http://en.wikipedia.org/wiki/Percentile）。

说白了就是将一组数据从大到小排序，并计算相应的累计百分位，则某一百分位所对应数据的值就称为这一百分位的百分位数。

2.Error% 
这个不说了，大家都懂。

3.Throughput  

这又是个很重要的参数了，开头提到的PV计算就跟这个数有关了。
计算公式见下图，通过Throughput可以换算出PV，当然为了应付突发状况还要留出一定的Buffer。
所以现在回到开头的那个问题，理论上每秒231的事务数就可以（10000000*0.8）/（24*60*60*0.4），当然这只是理论上;-)

4.KB/Sec
这个不细说了，跟计算你的机房带宽有关的。

二、图形结果 
这里比较重要的参数是偏离量。
偏离量，理论上是越小系统稳定的。但多少是小呢？所以这种说法是不准确的，“朝菌不知晦朔，蟪蛄不知春秋”，在不同的场景下对标准的定义也是不同的。

因为对正态分布和置信区间这块我也不太懂，这里就不敢瞎说了。

三、结果树
请求的执行状态，这里略。