背景说明：

很多小伙伴经常在群里发牢骚，说这个jmeter太破了，执行着执行着就卡死了。你猜猜我会是什么反应，我只能摆摆头默默的苦笑，想都不用想，就知道为什么那么卡，他犯了什么错。知道为什么？只要你使用jmeter，我相信GUI模式下的第一个启动窗口你一定绕不过：

对于这个黑色的命令行窗口，有多少人静下心来仔细读过上个几遍，短短几行字蕴含了多少知识量，知识在哪里，技巧在哪里，其实都隐藏在你默默忽略的一行一行帮助文档中，这就是我反反复复提醒各位小伙伴们，为啥学习的时候，最好的资料莫过于帮助文档了！今天要讲的就是在使用JMeter 开展性能测试时，我们需要做哪些基础的优化工作，避免不必要的问题产生。说实话，下面整理的内容，我也是循序渐进的把JMeter的帮助文档看完了，在平 时学习的过程中，逐渐做笔记，把一些重要的技巧和方法记录下来，对帮助文档进行了一个汇总和梳理，或者说把英文的东西按照自己的理解做了个翻译而已，并没 有做知识的创造和创新。

 

负载测试前的优化工作：

1、官方建议选择JMeter最新的版本使用，当前最新的版本为3.2，我本人使用的是3.1，毕竟开源的软件测试工作不会做的过于全面和细致，所以不想成为小白鼠，或者遇到莫名其妙的问题可能官方论坛也找不到答案。我使用大多数软件都是比最新版本低1-2个子版本。

2、JMeter3.0、JMeter3.1需要在JDK7.*和JDK8.*上运行；JMeter3.2需要执行在JDK8上面，而且官方明确提到JMeter3.2在JDK9上还没来得及全面测试，所以最好按照官方的说明，确保使用JDK版本的正确性，否则会出现一些莫名其妙的问题或者一些不兼容的问题。

查看java版本命令：java -version

查看jemter版本命令：jmeter -v

3、由于操作系统限制，每个操作系统限制了进程数和线程数，如果OS线程最大数不足，单负载压力机并发线程数超过OS限制时会报错。

4、JMeter的界面模式（GUI模式）是用来进行脚本编写和调试的，在正式执行时，强烈建议使用命令行模式（no-GUI模式）去执行，具体命令行执行请参考前面的文章。

5、压力执行机最好是4核8G或更高配置的机器；否则更低配置的机器，只适合拿来做脚本的编写和调试用，如果做脚本并发调试时，并发量最好不要超过100，否则jmeter容易卡死，更不要在GUI模式下做脚本并发测试，即使并发调试时线程数也不应超过50。

6、默认情况下，JMeter的JVM堆栈为512M，如果负载压力超过100个时，很可能JMeter自己会报错（out of memory之类的内存溢出错误），所以需要根据机器总物理内存调整并发数，JVM堆栈分配4G时，承受500-1000的并发量问题不大。

· windows环境下，修改jmeter.bat：

set HEAP=-Xms256m -Xmx256m

set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m

改为：

set HEAP=-Xms512m -Xmx1024m

set NEW=-XX:NewSize=128m -XX:MaxNewSize=512m

· linux环境下，修改jmeter.sh：

java $JVM_ARGS -Xms2048m -Xmx4096m -XX:MaxPermSize=512m -Dapple.laf.useScreenMenuBar=true -jar `dirname $0`/ApacheJMeter.jar “$@”

说明：堆栈大小的设置，最好设置为4G左右，内存太小承受的并发数太少，太大会导致jvm垃圾回收系列问题（具体原因此处不解释，可以百度java堆栈内存设置方面，这和jmeter本身无关，只和jvm的原理有关）。其它情况下，需要根据实际情况调整。

7、命令行执行时候的日志，尽量选择csv日志，不建议选择xml文件日志（xml日志信息更丰富，但是会增大压力机负载，降低并发数量，按照个人经验，xml格式的日志适合接口自动化测试，csv格式的日志适合接口性能测试）

8、性能测试脚本尽量保持简洁，只保留最基本的检查点即可，否则逻辑太复杂，也会降低单机的并发数量。

9、性能测试脚本中不要添加监听器去查看日志结果，如果想保留，性能测试前，需要将其注释掉（也就是将其置为unenabled状态），或者你在命令行执行的时候，增加-l选项，脚本中的监听器日志文件保存会自动屏蔽掉。

 

备注：只讲干货，将知识的本质和原理辅以例子，让你学起来知其然并且知其所以然，让你一次的学习解决一类知识点！让我们一起学习并快乐着。如果觉得好，请动动手指转发吧，做一个知识的传播者，share knowledge with the world！