Jmete脚本混压比例配置方法

项目压测中常常需要分析业务模型，通过线上流量占比计算出不同业务下的接口访问比例，然后脚本中设置比例进行混压，模拟线上用户访问场景。常用的混压比例配置方法有两种：多线程设置不同并发和吞吐量控制器。

一. 多线程组

如下两个接口：马蜂窝旅游和当当网，假设线上业务流量计算出来模型比例是马蜂窝旅游%30:当当网%70。由于无法真正控制最终的吞吐量按照这个比例，因此控制并发比例为3:7，看最终qps结果。

1. 如下设置并发马蜂窝6，当当网14。

压测数据如下：总并发20，qps399。当当网qps374.92，马蜂窝旅游：24.98。最终qps占比几乎是94%：6%，与预期的差距过大。

1.1. 为何qps与设置的并发比例完全不一致？

与耗时有很大关系。当当网95分位耗时46ms，共14个线程，预估吞吐量=14/0.046s=305/sec；马蜂窝接口95分位耗时303ms，6个线程，预估吞吐量=6/0.303s=19.8/sec。计算的结果与压测结果接近。那实际业务压测中，如何让qps更接近线上流量统计出来的模型呢？

1.2. 调整某一接口并发，根据耗时计算并发

刚才总的压测qps为400左右，按照比例，当当网应该为280，马蜂窝接口为120。那么当当网应该降低并发，实际qps/预估qps=375/280=（约等于）1.33，实际并发/1.33=14/1.33=10（约等于）；马蜂窝接口应该提高并发，实际qps/预估qps=25/120=0.2，实际并发/0.2=30

1.3. 如下设置并发马蜂窝30，当当网10

压测数据如下：总并发40，qps367。当当网qps234，马蜂窝旅游：132。最终qps占比几乎是65%：35%，与预期3:7已经很接近了。

二. 吞吐量控制器

看下官网对于吞吐量控制器的概念：The Throughput Controller allows the user to control how often it is executed

（吞吐量控制器允许用户控制执行频率）。作用在同一个线程组下，不同接口添加不同的控制器，选择按照百分比执行，吞吐量字段按照比例设置树数值。

1. 如下设置并发马蜂窝6，当当网14。

与多线程组一样，压测马蜂窝和当当网接口，设置同样的并发。总qps188.88，当当网qps132.22，马蜂窝旅游：56.66。最终qps占比几乎是71%：31%，与预期比例几乎一样。

如上的压测结果虽然与我们的预期一致，但是却产生了2个问题：

1.1. 为什么同样的并发，使用吞吐量控制器后，压测结果几乎降了一半？

1）同一线程组下，执行方式是串行，也就是说前一个请求完成响应后，才能进行下一个。可以简单测试下：

以下3个请求的启动时间就可以看出是按照顺序执行的。

开始时间是46分45s，加载时长261ms

开始时间是46分45s，加载时长459ms

开始时长变成了46分46s，原因是前2个请求加载时间接近1s

2）jmeter工具是以线程的方式运行，通过线程组来驱动多线程运行测试脚本，是一个jmeter脚本能跑起来的基本。而吞吐量控制器属于逻辑控制器，使用后jmeter还需加载和调用其中的算法，肯定要比不使用该控件要耗费时间。

1.2. 那如何能达到多线程组执行后的数据呢？

等比放大并发。总并发增加从20增加至40，同样单个接口并发放大2倍。压测总qps386.89，当当网qps270.84，马蜂窝旅游：116.55。最终qps占比几乎是70%：30%，与预期比例几乎一样。

再来看一个例子：某实际项目压测数据

使用吞吐量控制器按照业务比例控制，总qps7.43k+7.42k，共1.45w

使用多线程组并发控制：总qps40.64+40.13k，共8w

优缺点对比：

多线程组：请求是并行的，同样并发qps更高，但压测后的qps比例会失调，需要人工调整

吞吐量控制器：请求是串行的，同样的并发qps更低，但压测后的qps始终保持配置的比例

（遗留问题：为什么官方文档说了并不能控制吞吐量，但实际结果却与比例设置几乎一样呢？）