【性能测试】吞吐量上不去的问题

在做一个项目的性能测试，发现增大并发用户数的时候，响应时间没有增加，但tps并没有提升，这并不符合“逻辑”
线程数：300+100

线程数：750+250

一、是否被测服务带宽等原因引起

将被测服务扩容且分布不同但宿主机，得到的数据和改变后无差别，且此时的被测服务的cpu、网络等指标均正常，故可以排除该可能性

二、是否是客户端肉鸡出现了时间误差导致

线程数：100

同步所有肉鸡的时间后

故排除该可能

三、是否是单台肉鸡扛不住并发数量

单肉鸡线程数：8+24
注：怀疑单台客户端肉鸡扛不住这样的并发量，在每个请求后都等待20ms
客户端肉鸡数10

客户端肉鸡数11

很明显不是这个原因

四、单个客户端肉鸡和多个的并发能力差异

单肉鸡线程数：5+15
客户端肉鸡数：11

客户端肉鸡数：1

可以发现单个客户端肉鸡基本上可以处理2600个请求/秒，但是11个客户端肉鸡并发时，被测服务响应但平均值基本不变的情况下，仅仅为3600个/秒，可以猜测是否是因为客户端肉鸡的控制端出现了问题？

五、去掉控制端错误信息收集

单肉鸡线程数：5+15
客户端肉鸡数：11

和之前的数据对比，发现基本没有改变

六、禁用断言信息

单肉鸡线程数：5+15
客户端肉鸡数：11

从3600 到 3800，无本质的区别

七、禁用查看结果树信息收集

单肉鸡线程数：5+15
客户端肉鸡数：11

在平均响应时间增加的情况下，处理的请求猛增为7200个/秒

八、去掉聚合报告中信息收集

单肉鸡线程数：5+15
客户端肉鸡数：11

多次尝试，发现并没有较大的改变

从上面数据可以看出，每秒接收的数据量都小于6000KB/S，是否是因为各个客户端肉鸡需要回传数据给中控端，此时中控端的带宽不足以支撑数据的回传导致阻塞？

九、将中控端更换无限制的千兆网络环境

单肉鸡线程数：5+15
客户端肉鸡数：11

可以看到请求处理的速度又猛增为10200，通过以上实验可以发现，主要的影响因素有：

1. 查看结果树
2. 中控端网络环境
3. 断言信息
4. 聚合报告信息

那如果需要更大的吞吐量时应该怎么处理？中控端更换更牛逼的网络环境？
因为并不是单次集合点并发请求，需要基本在同一时刻发起请求
其实，可以直接使用命令行分别启动各个肉鸡的jmeter服务，仅需要关注被测服务的请求监控数据即可，这样就可以直接绕过中控端数据收集的环节，直接解决问题