在做一个项目的性能测试，发现增大并发用户数的时候，响应时间没有增加，但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，通过以上实验可以发现，主要的影响因素有：
- 查看结果树
- 中控端网络环境
- 断言信息
- 聚合报告信息
那如果需要更大的吞吐量时应该怎么处理？中控端更换更牛逼的网络环境？
因为并不是单次集合点并发请求，需要基本在同一时刻发起请求
其实，可以直接使用命令行分别启动各个肉鸡的jmeter服务，仅需要关注被测服务的请求监控数据即可，这样就可以直接绕过中控端数据收集的环节，直接解决问题