近期参与过一个红包雨的功能开发，并与测试人员一起工作完成了这个功能的压测。该项目是针对国外项目进行的，并使用了公司的经费，使用了AWS服务器进行了压力测试。由于该功能只是短期使用，公司无法承受大量资金燃烧，因此该功能在产品上线后不久便停止了使用。
由于该项目是公司内部的，因此无法向外界透露。此外，我虽然曾经参与过该项目的压测工作，但并未独立完成过压测工作，因此并不太放心。因此，为了更好地掌握压测技术，并掌握实际操作的经验，我选择在阿里云上花费个人资金进行了压测。总的来说，压测工作消耗资金较多，几个小时几十块钱的花费会让人倍感痛苦。
测试代码
正常一个接口响应时间需要控制在500毫秒以内，也就是0.5秒，这里我通过模拟业务正常响应时间给了0.3秒，打成一个jar包，然后通过一些脚本，让这个jar包开机自启动，同时通过配置弹性伸缩和负载均衡来进行扩容处理。
@GetMapping("/test")
public String test(){
try {
Thread.sleep(300);
} catch (InterruptedException e) {
e.printStackTrace();
return "压测出错啦";
}
return "压测";
}
制作脚本的文章也给到你们：
https://blog.csdn.net/java_wxid/article/details/132921871?spm=1001.2014.3001.5501
在30秒内有5000个用户，每个用户每秒请求5次
在30秒内有5000个用户，每个用户每秒请求5次，需要5台2核4G的，3台扛不住，我试过了。阿里那边的客服和文档都提过这个事情，5000并发基本都是5个以上。
在30秒内有15000个用户，每个用户每秒请求5次
根据上面的推断，5000个用户30秒内，每个用户5次请求，需要5台2核4g的服务器，那么20000个用户可以是四倍的服务器数量，对吧。然后试过之后发现，异常概率太高，扛不住。于是我降到15000个用户，心想这应该够用了吧，发现还是不行。
然后看网上的说需要调大jemter的内存，我主机是16核心24线程64g内存，把jemter调个20g应该够用了吧，发现结果还是差不多。
然后我又想了一个思路，一台机器可能测不了那么多，因为1万用户的时候是可以保证接口没有异常的，1万5就不行了，服务器数量我认为是足够了，负载均衡clb最高1百万并发更加没问题，那么我就分3台机器测2万用户，在30秒内，每个用户每秒请求5次，因为其他二台笔记本性能不如台式机，每台笔记本5000线程，台式机直接1万，3台电脑分别用不同的网络，我用3台手机分别开3个热点，同时开始进行压测，这样总可以了吧。
不断调试
执行后发现，三台压测都有异常，首先猜测的就是抗不住，但是看了监控发现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云服务器上压不到二万的问题，因为选择压测云盘规格选择错了，单台上限就这么多。下篇文章回答弹性伸缩为什么在压测环境下没法做到扩容的问题。
应该选这个云盘
