(文章目录)
工作多年，之前在公司弄过一个红包雨的功能，当时是做国外的项目，和测试一起做的，他为主导，我协助，用公司的钱做的压测，服务器是用的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千多。
上述如果有不对的地方，还请大佬指正。