jmeter的kafka的压测工具 jmeter压测问题

Jmeter进行高并发压测常见的问题

• 高并发压测时jmeter工具的瓶颈

• 一。端口不够用
• 二。线程数
• 三。内存不足
• 四。带宽瓶颈
• 五。分布式压测
• 六。建议

• 参考资料

高并发压测时jmeter工具的瓶颈

【前言】我们在进行高并发等性能压测时，通常会选择jmeter工具。该工具基于Java实现的，支持接口并发、能够模拟各种协议请求（http，websocket等）、导入相关的jar包后可以直接运行java程序、支持写自己的脚本等，基本上能够全面的模拟通用业务流程的场景。不过任何软件都存在瓶颈，jmeter支持大并发请求，也不是无限大。当并发量超过一定值时jmeter本身就会出现一定的瓶颈，会影响到性能测试的效果。最近做了一个支持10w用户并发直播的项目，进行性能测试期间遇到了各种各样影响性能测试效果的因素，其中发现了几个jmeter工具的问题，在此小计一下。

@以下是jmeter支持的协议：

一。端口不够用

压测的线程数过多时，或者线程没有被及时释放，会导致系统开放的TCP/IP连接端口已达到最大限制，jmeter会直接报错。

【报错信息】：java.net.BindException：Address already in use.

【原因分析】：Windows提供给TCPIP连接的端口为1024-5000，并且要四分钟左右循环回收，这就导致我们短时间内频繁调用大量请求时，端口将被占满。

【解决方案】：

• 1.打开注册表：在cmd（win+R）中输入regedit，打开注册表；
• 2.设置系统参数：最大端口连接数。
  ①找到系统参数设置项：\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
  ②右击parameters，添加一个新的DWORD，参数名为MaxUserPort；
  ③双击MaxMaxUserPort，输入数值为65534，基数选择十进制；
  ④重启电脑！重启电脑！重启电脑！

二。线程数

【异常现象】：大量请求出现连接失败，或者压测的错误率异常高！

【原因分析】：线程数已达到瓶颈。

【解决方案】

• 1.循环创建线程时，勾选keep-alive，可以复用线程。
• 2.扩大被测程序的线程池大小。（程序出现瓶颈时）

三。内存不足

【异常现象】：jmeter安装目录下产生大量很大的.hprof文件。
【原因分析】：这种.hprof文件的产生是内存泄露引起的。
【解决方法】：

• 1.升级jmeter压测机的硬件配置，增加内存空间；
• 2.修改jmeter的系统参数。
  ①打开jmeter.bat文件；
  ②修改jmeter压测机的内存使用大小：
  set HEAP=-Xms3g -Xmx3g -XX:MaxMetaspaceSize=768m（默认是1g，修改为3g）
• 3.检测被测程序，查找被测的软件程序是否存在内存泄露。
  

四。带宽瓶颈

【现象】：jmeter执行结果中出现了大量请求超时，但是被测程序的服务器却没有保错日志的情况。
【分析】：可能是主控机的带宽达到了瓶颈。
【解决方法】：

• 1.升级主控机的硬件配置，扩大带宽值，如：从100MB→500MB；
• 2.均分多个主控机，避免单主控机远程的执行机数量过多，最好控制在10个以内。

五。分布式压测

分布式测试有一些基本限制。 官方文档中有提到以下几项：

• 1.由于没有代理的情况下RMI无法跨子网通信； 因此，分布式压测时，JMeter的所有执行机最好放在同一网段。
• 2.从2.9版开始，JMeter将剥离响应数据的所有测试结果发送到控制台，这能够减少对网络IO的影响。 确保监视网络流量，以免引起流量争用情况。
• 3.单个JMeter客户端在处理器为2-3 GHz CPU的主机上运行时，可以处理1000-2000个线程，具体取决于测试的类型。
  （这个也取决于业务流程的复杂程度，如果业务流程中有涉及到长连接时，实测单个jmeter客户端只能较好的支持800-1000个线程）

六。建议

• 定期重启压测机，最好每次压测前都重启一下电脑。
• 定期清理jmeter生成的日志文件：jmeter.log & jmeter-server.log（安装目录下）。
• 分布式部署时，一台主控机最好只控制10台以内的执行机，避免主控机的带宽和内存达到瓶颈。
• 压测时需要监控下压测机的CPU、内存、网络和IO的资源使用情况。