说明 以下示例仅供参考，具体请以官方文档为准，请参见 官方文档 。 非活跃的线程，没有对应的吞吐量，按照上述示例（每分钟）：

线程组1：每个线程每分钟发出请求100次，即Sampler1.1和Sampler1.2各自的吞吐量都是100线程×100次/60秒=83左右。

线程组2：每个线程每分钟发出请求100次，即Sampler2.1和Sampler2.2各自的吞吐量都是200线程×100次/60秒=160左右。

配置到Sampler上即可控制到单个Sampler的吞吐量。

All active threads 将设置的吞吐量，分配到活跃的线程上（所有线程组的所有线程），然后这个线程在上次运行自行结束之后，等待合理时间（为了控制吞吐量）再次运行。 多线程组的时候，要求其他线程组也有一样的配置按照上述示例：

因为线程是一开始就发出去，所以在执行第二个Sampler的时候，吞吐量就会非常低。因为是从线程组维度控制的，每个线程吞吐量分别是每分钟为1和2，所以到第二个Sampler的时候，次数会减少。

线程组的Throughput是每分钟为100，全局的吞吐量是每分钟为200。

需要运行一段时间之后（线程组内多个Sampler发出去的请求数一致=并发数），每个线程组内Sampler的吞吐量才会趋于均衡。

All active threads in current thread group 将设置的吞吐量，分配到活跃的线程上（当前线程组的活跃线程），然后这个线程在上次运行自行结束之后，等待合理时间（为了控制吞吐量）再次运行。 单线程组的时候，与上一个相同。按照上述示例：

因两个Timer的配置一致，故和上述情况一致。

当把第二个Timer的吞吐量改为每分钟为200时，每个线程组可单独控制。

All active threads（shared） 将设置的吞吐量，分配到活跃的线程上（所有线程组的所有线程），所有线程都会在所有活跃线程运行结束之后即所有线程结束之后，等待合理时间（为了控制吞吐量）再次运行。 类似全场景的多次延迟释放，因为需要等待所有活跃线程运行结束，按照上述示例分析如下：

在压测过程中，可以看到不会有多个Sampler的数据同时变化。

已经发起过请求的线程会被暂停在第一个Sampler上。

全场景的Target Throughput是为每分钟100，且多个Timer的配置保持一致。

All active threads in current thread group（shared） 将设置的吞吐量，分配到活跃的线程上（当前线程组的活跃线程），所有线程都会在所有活跃线程运行结束之后即所有活跃线程结束之后，等待合理时间（为了控制吞吐量）再次运行。 当前线程组中，活跃线程组中线程结束之后，再等待一点时间运行。

线程组的Target Throughput为每分钟100，但每个线程会考虑全局其他活跃线程。

线程组的吞吐量可以单独配置和控制。

All active threads 全场景吞吐量控制驱动：多个线程组的业务模型类似，且全场景的吞吐量固定，即可拆分到单个线程组的均匀吞吐量。 单机并发线程是50，Target/2替换为脚本中的值，即单机上的吞吐量变成脚本中的一半为每分钟50。全局的吞吐量不变化仍然为每分钟100。当有多个线程组的时候，还会多个线程组累加。 单机并发线程是50，单机上的吞吐量为每分钟100，全局吞吐量变为脚本中的值×IP数，即为每分钟200。当有多个线程组的时候，还会多个线程组累加。 All active threads（shared） 全场景吞吐量不区分线程组，略低于多线程组配置值叠加。 线程组1配置是100，线程组2配置是200，则全局为150，即两个线程组的均值。 线程组1配置是100，线程组2配置是200，则单机为（100+200）/2，全局为300，但是单机多个Sampler达到均衡的时间更长。 All active threads in current thread group（shared） 线程组的吞吐量考虑全局活跃，略低于多线程组配置值叠加。 线程组1配置是100，线程组2配置是200，则全局为300，是线程组1和2的配置数累计之和。 线程组1配置是100，线程组2配置是200，则单机为100+200，全局为600，但是单机多个Sampler达到均衡的时间更短。