jmeter 相关参数

jmeter

————

————

Ramp-up Period（in seconds)

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

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

【3】Ramp-Up Period(in-seconds)代表隔多长时间执行，0代表同时并发

Delay Thread creation until needed

延迟创建线程，直到该线程开始采样，即之后的任何线程组延迟和加速时间为线程本身。这样可以支持更多的线程，但不会有太多是同时处于活动状态。

首先，假如要使用大量线程的话，ramp-up period 一般不要设置成零。

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

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

假设：

线程数：n

Ramp-Up Period：T （有人称之为启动时间，有人说是准备时长，看个人喜好）

循环次数：a

若每个循环运行时间是 t

当时间到 S = (T- T/n)时，最后一个线程启动，若要使所有线程同时运作，则需要在最后一个线程启动的时候第一个线程仍未关闭，为达到这个要求，需满足 a·t > S及a > S/t

每一个个线程运行时间既是R = a·t(此处的a是大于S/t的某一值)，则第一个线程在时间点为R 的时候停止，整个测试理论运行时间则是 ：S + R = (1-1/n)·T + a·t

总结：

测试中变量是 线程数 n ，每个循环时间 t 是个实践值，循环次数 a 只是为了延长单个线程的运行时间，从而保证当最后一个线程启动时，所有线程都在运行中，达到压测效果。

我们设置线程数 n = 5，循环次数a = 1000，请求www.google.com，得到聚合报告如图：

图中得到谷歌首页的平均请求时间大约为t = 0.2秒

这里，我们为了方便分析，将Ramp-Up Period 设置为T = 10秒（实际合理的时间后面会说明）

依然是n = 5，得到 S = (T- T/n) = 8 ，也就是说，从第一个线程启动到第8秒的时候，最后一个线程开始启动，若需要在最后一个线程启动的时候第一个线程仍未关闭，则需要满足 a·t > S ，已知S = 8,t = 0.2，得到 a > 40 。

OK，既然循环次数要大于40，我们不妨把循环设置成100，那么单个线程运行时间就是R = a·t = 20秒，也就是说第一个线程会在第20秒的时候停止，整个测试的理论运行时间为 S + R = (1-1/n)·T + a·t = 28秒

我们用一张图来直观的看看每个线程的运行情况

从图中可以得到从第8秒开始，到第20秒，5个线程同时在运行中，此时才是真正的模拟5个用户同时并发

Thruoghput

TPS=(sample样本数)/(最后一个线程启动的时间+最后一个线程持续的时间-第一个线程启动的时间)

RT=所有sample样本响应时间和/样本个数

TPS：每秒处理的事务数

jmeter的Throughput为吞吐率（请求数/秒），在加了事务控制器后，TPS=Throughput

宏观上：TPS=并发数/响应时间，jmeter的Throughput = (number of requests) / (total time) ，即

Throughput =(sample样本数)/(最后一个线程启动的时间+最后一个线程持续的时间-第一个线程启动的时间)

可以这样理解这个公式：绝对的并发是不存在的，请求发出的时间总有先后，绝对的TPS也是无法计算的，统计的角度看，服务器处理请求总数/花费的时间即是TPS，这也是

为什么需要不断增大用户数来寻找服务器的最大TPS的原因

平均响应时间=所有sample样本响应时间和/样本个数

误区：

TPS=请求数/RT   (RT是所有事物的平均时间) 

此TPS的计算公式是错误的

数学公式法：

TPS= (number of requests) / (total time) --------公式1 TPS的定义公式

TPS=1/RT * 请求数 = 样本个数2/所有sample样本响应时间和 -----------公式2 带入公式 平均响应时间=所有sample样本响应时间和/样本个数

假设公式2等于公式1 ，则

(number of requests) / (total time) = 样本个数2/所有sample样本响应时间和

即：

1/ (total time) = 样本个数 / 所有sample样本响应时间和

显然等式两边不成立，假设不成立

另：number of requests 是等于 样本个数 等于 请求数

所有sample样本响应时间和

显然等式两边不成立，假设不成立

另：number of requests 是等于 样本个数 等于 请求数