jemeter压测【2万用户每秒5次请求在30秒内处理完请求】

近期参与过一个红包雨的功能开发，并与测试人员一起工作完成了这个功能的压测。该项目是针对国外项目进行的，并使用了公司的经费，使用了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千多。

上述如果有不对的地方，还请大佬指正。