jmeter使用

线程组

在测试计划中，创建一个线程组。在jmeter中线程就是用户的概念，想模拟多个用户的请求，就创建一个线程组。

比如我们创建如下

• 创建一个 取样器 > HTTP请求，我们要模拟一个接口调用。
• 创建一个 配置元件 > HTTP头信息管理器, 我们可以添加固定的Authorization存接口的token值。
• 创建一个 监听器 > 用表格查看结果。

线程组的配置如下：①线程数： 10  ②Ramp-Up时间(秒)： 50  ③循环次数：2

我们执行一次看看表格结果：

总结：

线程数就是用户数量，配置10，也就这次执行中，会有10个线程（用户）模拟采样器配置的http请求。

Ramp-Up配置50秒，就是在50秒内启动完所有线程，那么就是平均5秒1个。

循环次数2，就是这些线程创建后就立马执行请求，会连续执行两次请求，中间没有间隔（想要调整间隔时间需要用到定时器）。

看上图可以发现，当第19个请求，到第20个请求之间的间隔，就是19个请求的用时，说明一个线程执行两个请求是连续的，无间隔的。

定时器使用

固定定时器

一个线程（用户）可以发送多个请求，每个请求之间默认是没有间隔的，一个执行完成后立马下一个，相差的时间就是执行用时。如果想要让一个请求之后有一个固定的延迟时间，就需要用到“固定定时器”。

我们把线程组的 ①线程数 2 ② Ramp-Up时间 2秒 ③ 循环次数2

在10:28:20时执行，可以看到2秒内（22秒）启动了2个线程。

每个线程执行一个请求后，会延迟3秒执行下一个请求。

统一随机定时器

这个是让一个线程暂停一个随机时间。它会产生延迟的时间是一个随机值，各值出现的概率均等。用户可以设置 “最大随机延迟时间” 和 “固定延迟时间”，每个线程的延迟时间是符合标准正态分布的随机时间停顿，那么使用这个定时器，总延迟 = 高斯分布值（平均0.0和标准偏差1.0）* 指定的偏差值+固定延迟偏移。

我们把线程组的 ①线程数1  ② Ramp-Up时间 0秒 ③ 循环次数5

通过结果，可以看到，1个线程发送了一个5个请求，每个请求的间隔随机的，最少是1s，最大是6s。

固定吞吐量定时器

目标吞吐量： 是每分钟发送的请求数，对应测试需求中所要求的QPS。按指定的吞吐量执行，以每分钟为单位。计算吞吐量依据是最后一次线程的执行时延。

可以选择作用的线程：只有此线程、当前活动线程等。

• 只有此线程：设置每个线程的吞吐量，总的吞吐量=线程数*该值。
• 当前活动线程： 吞吐量被分摊到当前线程组所有的活动线程上。每个线程将根据上次运行时间延迟。

配置例子：

线程数：5， 持续时间(秒)：60

目标吞吐量：10

基于计算吞吐量： 只有此线程

实际运行：

运行了60s，每个线程10个请求，一共50个。

准确的吞吐量定时器

通过控制吞吐量来更精准的控制请求，它是根据吞吐量做计时器（到了多少量就发请求），能控制请求的速度和个数。

上图，线程数 5，Ramp-Up时间1秒。 代表1秒内把5个线程启动起来。

循环次数 【永远】， 勾选调度器，持续时间【60秒】。代表运行时跑60s。

这个“持续时间(秒)” 最好要和定时器中设置的“测试持续时间(秒)” 保持一致，比如这里都是 【6秒】。如果持续时间小于准确的吞吐量定时器中的测试持续时间，则按线程组的持续时间。

目标吞吐量(每个吞吐期的样本)： 期望测试的TPS，在下面配置的周期内总的请求数量。

吞吐量周期(秒)： 在多少秒内执行测试的TPS。

持续测试时间(秒)：测试时长，与前面线程组的调度器持续时间保持一致即可。比如都是6s。

批处理中的线程数(线程)： 是指准备好了多少个线程后一起发起请求(即集合点)，取TPS保持一致的数值。

批处理中的线程之间的延迟(ms): 第一批和第二批处理之间的延迟时间，默认即可。

配置例子一：

线程数：5， 持续时间(秒)：40

目标吞吐量：5，  吞吐量周期：10，测试持续时间(秒)：40

批处理中的线程数： 1， 批处理中的线程之间的延迟(ms): 0

实际运行：

只要有线程启动就发送请求，5个线程陆续启动，陆续执行请求。保证大体在10s发送5个，40s运行时间内，一共发送20个请求。

配置例子二：

线程数：5， 持续时间(秒)：40

目标吞吐量：5，  吞吐量周期：10，测试持续时间(秒)：40

批处理中的线程数： 5， 批处理中的线程之间的延迟(ms): 0

实际运行：

这个和上面的例子一，唯一的差别就是批处理中的线程数设置了5，也就是要等5个线程都准备好了以后一起执行。

配置例子三：

目标吞吐量：1000，  吞吐量周期：1，测试持续时间(秒)：3

批处理中的线程数： 1， 批处理中的线程之间的延迟(ms): 0

实际运行：

一个请求，平均83ms，1个线程去跑，1s中也就12个。3s就是36个。5个线程去跑，那么3s也就150-160个。所以虽然我们配置希望1s发送1000次，但是5个线程跑不到这个量，所以可以看到最终也就发了157次请求。