关于jmeter:运维攻坚之jmeter压力测试报错

背景

某客户施行 DAP，在上线前须要对 DAP 进行压力测试，有专门的压力测试环境，并且要求并发可能达到 1000，团队应用 jmeter 作为压测工具，整个零碎架构很简略 浏览器 ->Nginx->Tomcat，在压测的时候碰到以下问题

• 对 DAP 流程提交接口进行压测，压测不通过
• 部署一个仅仅返回申请参数，没有任何业务逻辑，压测不通过
• 绕过 Nginx，间接对 Tomcat 进行压测，压测通过
• 间接对 Nginx 进行压测，压测 Nginx welcome 页面，压测不通过

并且对 Nginx 进行了大量的调优，能调的参数根本都试过，压测不通过，总结下来就是，只有通过 Nginx，压测就不通过，看来问题呈现在 Nginx 上

环境信息

• Nginx：16CPU 64G 内存
• Nginx 配置，这里只列几个比拟重要的参数

worker_processes 16;
worker_connections 1000;
keepalive_timeout 60;

这些参数都调整过，对后果影响不大，当然如果调的太极其，比方 worker_processes 设置为 1，必定是会报错的。

• Tomcat：16CPU 64G 内存

这个配置 Nginx 跑 1000 并发齐全是足够的

排查

先看下两个测试后果比照

• 压测 tomcat 简略接口，并发 1000，循环 50 次，总共 50000 次申请

压测后果

所有申请没有呈现 Error

• 压测 Nginx welcome 页面，并发 1000，循环 50 次，总共 50000 次申请

有百分之 0.31% 的错误率，尽管不高，但这个错误率是始终有的，而且如果说 Nginx 的压测不如 Tomcat，置信这个后果大家都承受不了，Nginx 是负载平衡产品中公认最强的产品，一个是负载平衡，一个是应用服务器，负载平衡最重要的就是并发能力，应用服务器最重要的是业务能力，如果 Tomcat 在并发能力上超过 Nginx，可能会颠覆很多人的认知。所以这其中必定是有问题的。

Nginx 压测申请的谬误次要集中在以下几点

• java.net.ConnectionException: Connection refused: connect
• java.net.SocketException: Connection reset
• java.net.SocketException: Unexpected end of file from server
• org.apache.http.NoHttpResponseException: failed to respond

基本上是网络谬误，为了排除网络谬误，做了两个测试

本地运行

我本人电脑（MAC）开 nginx 和 tomcat，用 jmeter 进行压测，后果更不现实，也是 1000 并发

尽管有这么高的错误率，然而不论是 nginx 还是 tomcat，并没有报错，这能阐明什么问题呢，阐明很可能是内核层面就报错了，也就是申请基本就没进来

Linux 主机运行

Jmeter 反对在 LInux 下运行，也反对命令行模式，因而能够思考在内网服务器找一台同网段主机作为压测机器，步骤如下

• 将 jmeter 安装包上传到 Linux 压测机并解压
• 在本地配好测试计划，保留为 jmx 文件，并将 jmx 文件上传至 Linux 压测机
• 执行以下命令以命令行模式开启压测

apache-jmeter-5.4.1/bin/jmeter.sh -n -t plan.jmx -l plan.jtl

• 将后果文件 plan.jtl 下载到本地，在汇总报告中点击 Browser 关上文件

错误率为 0，联合本地运行的后果，能够猜想跟压测机的环境无关。

压测机

本次应用的压测机是一台 windows 7 主机，如果是压测机的起因，那么为什么压 tomcat 就没问题，压 nginx 就有问题，两次压测到底区别在哪，咱们能够用 wireshark 进行抓包，看两次压测在网络包上有什么不同

• Nginx 压测抓包，发现有大量 RST 的包，并且继续疾速呈现

RST 是连贯敞开时会发送的数据包

• Tomcat 压测抓包也有 RST 的包，然而速度显著较慢，而且数量不多

也就是说，Nginx 压测一直在创立连贯和敞开连贯，tomact 创立连贯和敞开连贯动作并没有那么频繁，咱们能够在 windows 上用以下命令查看连贯状况

netstat -a | find /i /c "TIME_WAIT"

该命令能够统计以后零碎处于 TIME_WAIT 状态的连接数，TIME_WAIT 示意连贯处于行将敞开的状态，这时候连贯所占用的端口仍然无奈开释，无奈进行再次调配，如果短时间内产生大量的 TIME_WAIT 连贯，容易导致端口号耗尽以至于无奈创立新的连贯，服务无奈响应

• Tomcat 压测 TIME_WAIT 连接数状况

TIME_WAIT示意期待敞开的连接数，能够看到迟缓增长，并且达到两千左右进行增长

• Nginx 压测 TIME_WAIT 连接数状况

能够看到快速增长，并且总数能够达到 2w 以上，最多能够达到 4w，所以两次压测的区别就是 TIME_WAIT 的数量，那为什么会产生这种后果，以下是我的集体猜想

nginx 采纳的是 epoll 非阻塞模型，tomcat 采纳的是线程模型，一个申请一个线程，属于阻塞模型，所以 nginx 能够段时间内 ” 吃掉 ” 大量的连贯，tomcat 须要排队进入，这样就造成了以上景象，nginx 短时间创立大量连贯，tomcat 则是迟缓减少连贯

论断

windows 作为压测机进行高并发压测并不适合，因为会在短时间内产生大量连贯，windows 作为工作 PC，在这方面解决能力不如 Linux，加上网络稳定等因素，容易造成谬误，造成压测后果失真，尽管能够通过优化局部参数升高错误率，但解决不了基本问题，倡议通过同网段 Linux 主机作为压测机，测试计划能够在 windows 进行配置，后果剖析也能够在 windows 中实现，但执行测试工作倡议在 Linux 主机上进行。