常用的逻辑控制器：
1、仅一次控制器
使用场景：线程数为1，登录1次，循环浏览N次。
如果，登录账号参数化，线程数为M时，登录M个不同的账号，每个账号浏览N次。
2、循环控制器
使用场景：循环控制器下的请求回循环
一个线程数的循环数 = 线程组的循环次数 x 循环控制器的循环次数
3、固定定时器，BeanShell Timer
只要线程组下有“固定定时器”或者“BeanShell Timer”，这个线程组的所有请求，都会先等待一个“固定时长”，再执行
例如：
点击执行后：等待3秒→发送“门店APP登录”→等待3秒→发送“if控制器里面的内容”
或者添加“BeanShell Timer”，写入脚本：Thread.sleep(3000);
实现的效果一样
4、Synchronizing Timer（同步定时器）
集合点：一个请求的线程数达到要求后，或者等待时间到了，就执行。
可用于压测的并发数设置
这个同步定时器和loadrunner当中的集合点（rendezvous point）作用相似，其作用是：阻塞线程，直到指定的线程数量到达后，再一起释放，可以瞬间产生很大的压力（人多力量大- -哈哈！）
（1）Number of Simulated Users to Group by:模拟用户的数量，即指定同时释放的线程数数量
（2）Timeout in milliseconds（毫秒）:超时时间，即超时多少毫秒后同时释放指定的线程数
PS：超时时间为0时，默认无超时限制。
概念：
1、定时器是在每个sampler（采样器）之前执行的，而不是之后；
不管这个定时器的位置放在sampler之后，还是之下，他都在sampler之前得到执行。
2、定时器是有作用域的；当执行一个sampler之前时，所有当前作用域内的定时器都会被执行；
3、如果希望定时器仅应用其中一个sampler，则把该定时器作为子节点加入；
4、如果希望在sampler执行完之后再等待，则可以使用test action
实际运行过程中，可能出现请求数当不满足集合点设置的请求数时，JMeter一直卡顿在如下页面
解决办法是：设置同步定时器的超时时间。
同步定时器（Synchronizing Timer）的超时时间设置要求：
超时时间 > 请求集合数量 * 1000 / (线程数 / 线程加载时间)
简单的场景：
1、如果希望定时器仅应用其中一个sampler，则把该定时器作为子节点加入
下面这个案例：同步定时器只针对HTTP请求1有效，和HTTP请求2无关
2、希望同步定时器应用多个sampler
如下，执行HTTP请求1和HTTP请求2前都会执行同步定时器1、2。当执行一个sampler之前时，和sampler（采样器）处于相同作用域的定时器都会被执行；
注意点：
----- 集合点的位置一定要在Sample(采样器）之前才能生效吗???”
在Jmeter中，timer是在sampler之前执行的。不管这个定时器的位置放在sampler之后，还是之前。当然，如果有多个timer的时候，在相同作用域下，
会按上下顺序执行timer，这个就需要慎重放置timer的顺序；不过，为了更好的可读性，还是建议将timer放在对应的sampler前面 或 子节点中；