jmeter之【线程组、聚合报告、图形结果各参数介绍】

线程组中各参数介绍：

线程数：用于模拟真实用户数。一个虚拟用户占用一个进程或线程。1线程数=1用户数。假如线程数是100，就相当于模拟100个用户

注：

单机的线程数建议不超过1000（因为Windows环境下，最大线程数为1000；linux环境下，最大线程数为2000，所以建议线程数设置不超过1000）

Ramp-Up：预期线程组中的所有线程（用户）从启动-运行-释放的总时间

注：

①决定多长时间启动所有线程（所有线程跑完的时间）。如果使用10个线程，ramp-up period是100秒，那么JMeter用100秒使所有10个线程启动并运行。每个线程会在上一个线程启动后10秒（100/10）启动。Ramp-up需要要充足长以避免在启动测试时有一个太大的工作负载，并且要充足小以至于最后一个线程在第一个完成前启动。  一般设置ramp-up=线程数启动，并上下调整到所需的。

②用于告知JMeter 要在多长时间内建立全部的线程。默认值是0。如果未指定ramp-up period ，也就是说ramp-up period 为零， JMeter 将立即建立所有线程并发送访问请求。假设ramp-up period 设置成T 秒， 全部线程数设置成N个， JMeter 将每隔T/N秒建立一个线程。

③Ramp-Up Period(in-seconds)代表隔多长时间执行，0代表同时并发。若Ramp-Up为0，表示瞬时加压，所有线程都在初始状态时一起并发访问，从而引起不正常的初始访问峰值，很容易使服务器饱和。不是因为平均访问率高而是因为所有线程的第一次并发访问而引起的不正常的初始访问峰值，可以通过jmeter的聚合报告看到这种现象

eg:假如线程数为100，Ramp-Up为0，循环次数为1，则相当于100个用户（线程）同时执行一次任务

④Ramp-UP时间设置越大，性能曲线越平缓，这样容易找到压测瓶颈点。

但若Ramp-Up设置过大，一些线程还没有启动，初期启动的部分线程已经结束了，导致实际并发量会小于预期并发量

⑤确定一个合理的ramp-Up period的规则就是让初始点击率接近平均点击率（总线程/点击率），eg:线程数为100，预估的点击率为10次/秒，那么估计的理想ramp-Up period就是100/10=10秒

⑥确定一个适当的ramp-Up取决于两条规则：

1）第一个取样器的点击率（hit rate）是否接近其他取样器的平均值，从而能否避免ramp-Up过小
2）在最后一个线程启动时，第一个线程是否在真正结束了，最好二者的时间要尽可能长，以避免ramp-Up过大（查验jmeter日志）

 

循环次数：每个线程（用户）循环执行的次数（也可以叫做线程的迭代次数、重复发起请求的次数），默认一次。如果线程数为20 ，循环次数为100 ，那么每个线程发送100次请求，总请求数为20*100=2000。假如勾选“永远”，那么所有线程会一直发送请求，一到选择停止运行脚本，以此测试出最大并发数

延迟创建线程直到需要：当线程需要执行的时候，才会被创建，可以延迟线程的创建，减少不必要的资源损失；如果不勾选此选项，所有线程在开始时就全部被创建

调度器：设置线程的“持续时间”和“启动延迟”时间

首先勾选调度器-->

持续时间（秒）：控制脚本持续执行的时间（若持续时间倒了不能停止运行，检查是否有集合点错误，如，等不到50个线程，一直在等）

启动延迟（秒）：控制测试在多久后启动执行

在选择调度器的时候，必须选择“永远”，否则循环次数不够，执行会停止；（勾选永远，若还是不按规则停止执行，请查看脚本，是否有仅一次控制器）

---

聚合报告中各参数介绍：

 这些参数单位均为ms

样本：总共发送到服务器的请求数（如果模拟10个用户，每个用户迭代10次，那么这里显示100）

平均值：平均响应时间，默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以Transaction 为单位显示平均响应时间

中位数：50％ 用户的响应时间

90%百分位：所有transaction中90%的transaction的响应时间都小于xxx。一组数据由小到大进行排列，找到第90%个数的响应时长为317ms，数组中存在有90%的数将小于等于317ms。百分位数针对大量无规律数字统计具有意义。

（关于90%的理解可参考这位大佬的博客：https://www.cnblogs.com/jackei/archive/2006/11/11/557972.html）

最小值：最小响应时间

最大值：最大响应时间

异常%：出错率

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

---

 图形结果中各参数介绍：

样本数目：总共发送到服务器的请求数

最新样本：代表时间的数字，是服务器响应最后一个请求的时间

吞吐量：服务器每分钟处理的请求数

平均值：总运行时间除以发送到服务器的请求数

中值：时间的数字，有一半的服务器响应时间低于该值而另一半高于该值

偏离：服务器响应时间变化、离散程度测量值的大小

 

关于吞吐量的概念可参考这位大佬的博客：https://www.cnblogs.com/fnng/archive/2012/06/29/2570558.html

吞吐量

　　指在一次性能测试过程中网络上传输的数据量的总和。

　　对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，在容量规划的测试中，吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载能力，另外，在性能调优过程中，吞吐量指标也有重要的价值。如一个大型工厂，他们的生产效率与生产速度很快，一天生产10W吨的货物，结果工厂的运输能力不行，就两辆小型三轮车一天拉2吨的货物，比喻有些夸张，但我想说明的是这个运输能力是整个系统的瓶颈。

　　提示，用吞吐量来衡量一个系统的输出能力是极其不准确的，用个最简单的例子说明，一个水龙头开一天一夜，流出10吨水；10个水龙头开1秒钟，流出0.1吨水。当然是一个水龙头的吞吐量大。你能说1个水龙头的出水能力是10个水龙头的强？所以，我们要加单位时间，看谁1秒钟的出水量大。这就是吞吐率。

 

吞吐率

　　单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量。它是衡量网络性能的重要指标，通常情况下，吞吐率用“字节数/秒”来衡量，当然，你可以用“请求数/秒”和“页面数/秒”来衡量。其实，不管是一个请求还是一个页面，它的本质都是在网络上传输的数据，那么来表示数据的单位就是字节数。

　　不过以不同的方式表达的吞吐量可以说明不同层次的问题。例如，以字节数/秒方式表示的吞吐量主要受网络基础设置、服务器架构、应用服务器制约；以请求数/秒方式表示的吞吐量主要受应用服务器和应用代码的制约。

　　但是从业务的角度看，吞吐率也可以用“业务数/小时或天”、“访问人数/小时或天”、“页面访问量/小时或天”来衡量。例如，在银行卡审批系统中，可以用“千件/小时”来衡量系统的业务处理能力。那么，从用户的角度，一个表单提交可以得到一次审批。又引出来一个概念---事务。

 

事务

　　就是用户某一步或几步操作的集合。不过，我们要保证它有一个完整意义。比如用户对某一个页面的一次请求，用户对某系统的一次登录，淘宝用户对商品的一次确认支付过程。这些我们都可以看作一个事务。那么如何衡量服务器对事务的处理能力。又引出一个概念----TPS

 

TPS (Transaction Per second) 

　　每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标。

 

点击率（Hit Per Second）

点击率可以看做是TPS的一种特定情况。点击率更能体现用户端对服务器的压力。TPS更能体现服务器对客户请求的处理能力。

　　每秒钟用户向web服务器提交的HTTP请求数。这个指标是web 应用特有的一个指标；web应用是“请求-响应”模式，用户发一个申请，服务器就要处理一次，所以点击是web应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大。对服务器的压力也越大，点击率只是一个性能参考指标，重要的是分析点击时产生的影响。

需要注意的是，这里的点击不是指鼠标的一次“单击”操作，因为一次“单击”操作中，客户端可能向服务器发现多个HTTP请求。

 

吞吐量指标的作用：

　　再次将话题回归到吞吐量上，在我们的性能测试中查看吞吐量对我们的测试有什么意义呢。

　　1. 用户协助设计性能测试场景，以及衡量性能测试场景是否达到了预期的设计目标：在设计性能测试场景时，吞吐量可被用户协助设计性能测试场景，根据估算的吞吐量数据，可以对应到测试场景的事务发生频率，事务发生次数等；另外，在测试完成后，根据实际的吞吐量可以衡量测试是否达到了预期的目标。

　　2. 用于协助分析性能瓶颈：吞吐量的限制是性能瓶颈的一种重要表现形式，因此，有针对性地对吞吐量设计测试，可以协助尽快定位到性能瓶颈所在位置。