Jmeter plugin插件的分类
- Standard Set组件：对线程组进行了扩展，扩充了许多丰富图表的监听器，可以用Jmeter来监控服务器
- Extras Set组件：支持远程监控，图表展示更加丰富
- Extras with Libs Set组件：提供对JSON的支持，新增了JMS取样器
- WebDriver Set组件：与WebDriver进行了集成，进行自动化测试
- Hadoop Set组件：提供Hadoop测试组件
这里安装Standard Set来研究线程组，线程组对应着用户的数量，当然用户的数量有诸多可能，这个系列一并分析并总结。
安装后线程组的功能就更加丰富了
这里先从最常用的开始
Thread Group
在线程组 GUI 中，您可以控制模拟的用户数（线程数）、加速时间（启动所有线程所需的时间）、执行测试的次数，以及可选的启动并停止测试时间。
线程属性值
设置的线程属性值是预期压力值，而聚合报告是压力测试的实际结果
线程数
1线程数 = 1用户数，windows单台机器线程数一般1000左右
Ramp-Up时间 (秒)
- 预期线程组的所有线程从启动-运行-释放的总时间
- ramp up=0时，表示瞬时加压，启动线程的时间无限趋近于0
- 特别注意：在负载测试的时候，尽量把ramp up设置大一些，让性能曲线平缓，容易找到瓶颈点
注意事项：
1）Ramp-Up要设置稍长的时间避免瞬时加压：
大量线程时，若设置为0，相当于瞬时加压，即测试开始时启动全部线程并立即发生请求，会给服务器造成不合理的压力。
2）Ramp-Up要设置够短的时间来保证并发数：
Ramp-up必须设置合理的时间，保证最后一个线程在第一个线程完成之前开始运行，这样才能保证实际并发量。
若设置时间过长，则会导致实际并发量并会小于预期并发量：一些线程还没有启动，初期启动的部分线程已经结束了
循环次数
- 线程组的循环次数
- 若设置为永远，也就是在循环期间，jmeter将不停的发送请求，可以用来测试最大并发数
调度器
控制当前线程组执行的持续时间和启动延迟时间
持续时间：循环次数设置为永远或 -1 时，持续时间才会生效。循环次数有固定值且 -1，持续时间不会生效，以循环次数为准
一般而言，测试计划总时间（见右上角）> 持续时间 + 启动延迟，因为线程是逐步释放的，而不是瞬间释放。
例子：
若现在有一个查询功能，需要系统在5分钟内完成5000笔查询业务，同时90%的用户响应时间不超过3S，最大并发是多少？
需求分析：
实际上也就是要求5分钟完成5000次查询，最大并发数计算公式如下：
最大并发数=（单次响应时间 * 业务量）/总的业务时间
QPS: Queries Per Second，每秒查询率，是一台服务器每秒能够响应的查询次数（数据库中的每秒执行查询sql的次数）。
并发线程数 = QPS / ( 1000 / 平均耗时ms )
假设单线程下，单次请求的平均响应时间是 200ms。
最大并发数=（0.2s * 5000）/ 5*60 = 3.33，若设置Ramp-Up=1，线程组=4，持续时间=300，那么产生的查询量= 1 * 5 * 4 * 300 = 6000 ，这样设置是可以达到5分钟5000次查询的要求的。
网上水贴，广告贴太多了，翻了半天终于捞出来像样的帖子：https://blog.csdn.net/vicky_lov/article/details/84588234
先从一个简单的例子开始：
线程数：n = 2
Ramp-Up Period：T = 1
循环次数：永远
每一个线程的平均响应时间是 t = 800ms
持续时间：4s
那么2s内线程可以运行4/0.8 = 5次，1/2=0.5s=500ms，即第二个线程启动的时候，第一个线程还没结束0.8s>0.5s。这样就能形成两个有效并发数。我们把过程捋一下。
大致草图就是这样，先线程1启动，然后0.8s之后继续循环，在4s内共执行4次；0.5s后线程2启动，然后每隔0.8s循环启动，在4s内执行4次，我的理解就是这样，具体是怎么在Ramp-Up时间内启动这些线程的就不清楚了。
再来看一个例子，设置一定的循环次数，循环次数可以延长单个线程的运行时间。
假设：
线程数：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，T=10，根据公式 S = (T- T/n) = 8 ，也就是说，从第一个线程启动 到 第8秒的时候，最后一个线程开始启动，若需要在最后一个线程启动的时候第一个线程仍未关闭，则需要满足 a·t > S ，已知S = 8,t = 0.2，得到 a > 40 。
既然循环次数要大于40，我们不妨把循环设置成100，那么单个线程运行时间就是R = a·t = 20秒，也就是说第一个线程会在第20秒的时候停止，整个测试的理论运行时间为 S + R = (1-1/n)·T + a·t = 8 + 20 = 28s。
用一张图来看下每个线程的运行情况：
可以看到从第8秒开始，到第20秒，5个线程同时在运行中，此时才是真正的模拟5个用户同时并发
再来回顾一下性能测试的场景：https://zhuanlan.zhihu.com/p/35460011
- 单业务基准测试
- 单业务压力测试
- 单业务负载测试
- 综合业务基准测试
- 综合业务压力测试
- 综合业务负载测试
- 综合业务稳定性测试
可以看出来，Thread Group用来做单业务基准和压力测试都是可以的。