不断调试
执行后发现，三台压测都有异常，首先猜测的就是抗不住，但是看了监控发现cpu使用率也不高，然后负载均衡也一样，可以正常转发，为了验证不是服务器的问题，我把机器加到40台。
其他二台笔记本异常在5.31%、4%。
然后查看接口发现负载均衡那出问题了
查看了负载均衡的监控，没有流量超限的问题，timeout问题原因推测是客户端侧带宽不足或后端服务器未能成功建立连接。
为了验证这一想法，我准备在云服务器上安装jemeter，利用高带宽的云服务器压测2万并发，就不存在这种情况啦。
想到就去做啦，弄好jemeter之后，通过以下命令生成报告：
jmeter -n -t /opt/apache-jmeter-5.4.1/testplan/20000的压测.jmx -l redtest106.15.139.95.jtl
比较尴尬的是生成的报告只有1万的样本，吞吐量倒是有二千多。
因为服务器开了几十台收费还是比较贵的，我就没有慢慢排查原因了，直接简单粗暴的用二台机器压测，每台都是一万并发，二台高带宽的服务器同时压测，配置都是一样的，凑够二万并发量。
为了区分，我还特地整了台高配置的机器作为对比。
二台机器同时压测1万线程，在30秒内，循环5次，凑够2万并发
把这二个报告重新导入Windows的jemter查看。
可以发现在机器比较好的情况下压测的吞吐量是不同的，一个是2千多，一个是4千多。
压测只所以压到一万就上不去了是因为我压测的这台服务器的云盘最高就支持一万，想要更高需要换高配的云盘，这个在后面的压测文章中会重新调整，同时解答压测过程中遇到的实际问题，这篇文章就回答了jemter部署在单台linux云服务器上压不到二万的问题，因为选择压测云盘规格选择错了，单台上限就这么多。下篇文章回答弹性伸缩为什么在压测环境下没法做到扩容的问题。
应该选这个云盘
