在场景运行时，我们提到了Jmeter GUI方式比较占资源，其实不管是GUI方式还是非GUI方式，运行时都会占用一定资源，那我们有没有办法提高负载机性能呢？既然是纯Java 开发，我们就可以调整其性能参数，让其在JAVA虚拟机上运行起来更加顺畅，效率更高。
在Jmter工具安装路径，找到如下文件
\apache-jmeter-5.2.1\bin\jmeter.bat
if not defined JM_LAUNCH ( set JM_LAUNCH=java.exe)
if exist jmeter.bat goto winNT1if not defined JMETER_BIN ( set JMETER_BIN=%~dp0)
:winNT1rem On NT/2K grab all arguments at onceset JMETER_CMD_LINE_ARGS=%*
rem The following link describes the -XX options:rem http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
if not defined HEAP ( rem See the unix startup file for the rationale of the following parameters, rem including some tuning recommendations set HEAP=-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m)
if not defined GC_ALGO ( set GC_ALGO=-XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:G1ReservePercent=20)
set SYSTEM_PROPS=-Djava.security.egd=file:/dev/urandom
rem Always dump on OOM (does not cost anything unless triggered)set DUMP=-XX:+HeapDumpOnOutOfMemoryError其中set HEAP：设置JVM堆大小，-Xms1g设置初始堆大小为1GB，-Xmx为设置最大堆大小，-XX：MaxMetaspaceSize 为设置元数据空间大小。从JDK8 开始用元数据区代替以前的持久代（PermGen space）。
set GC_ALGO：设置内存回收策略，-XX：+UseG1GC就是我们常说的G1（Garbage-First）收集器，回收"年青代"和"年老代"内存，GC并行，使用时间相对比较短的停顿来达到很高的吞吐量，大堆上性能表现良好。
-XX：MaxGCPauseMillis=100 ，设置最大暂停时间为100毫秒，这是一个理论阈值，GC过程尽量再次时间内解决。
-XX：G1ReservePercent=20 预留多少内存用来防止晋升失败的情况，例如"年青代"要晋升到"年老代"，有的对象比较大，此时堆内存不够了，对象到不了"年老代"，晋升失败，我们可以预留一点内存防止这种情况发生：此配置的单位是百分比。
set DUMP=-XX:+HeapDumpOnOutOfMemoryError ，设置当内存溢出时DUMP内存的信息，这样的好处是在JVM崩溃后方便查看堆信息进行问题分析，找到内存溢出的原因。
建议只需要对如下参数进行修改即可：
-Xms
-Xmx
-XX：MaxMetaspaceSize
JDK版本保持在1.8以上，系统最好是64位。如果这样Jmeter产生的负载不够大，你的机器配置又不错，可以启动多个Jmeter实例，在一台负载机运行多个Jmeter，每一台启动的Jmeter都是一个独立的进程，端口号会自动分配，不用担心端口号的冲突问题。
在使用性能测试工具JMeter进行负载测试时，影响负载的因素（X因素）不仅限于被测系统的硬件和软件配置，还包括了JMeter自身的设置、网络环境以及测试设计等多个方面。以下是这些因素的具体描述：
JMeter自身设置
线程数（虚拟用户数）：这是模拟并发用户数量的关键参数。更多的线程意味着更大的并发压力，但同时也要求更高的资源消耗。如果线程数设置得过高，可能会导致JMeter所在的机器成为瓶颈。
Ramp-Up Period（准备时间）：指所有线程启动所需的时间。较短的Ramp-Up Period会导致短时间内大量请求涌入，给服务器带来突然的压力；而较长的Ramp-Up Period则可以更平滑地增加负载，避免初期冲击。
循环次数：决定了每个线程发送请求的次数。这会影响总的请求数量，进而影响到整体负载水平。例如，若线程数为100且循环次数为5，则总共会发出500个请求。
定时器与思考时间：通过设定定时器可以在请求之间引入延迟，模拟真实用户的操作间隔。这对于反映真实的用户体验非常重要，并且能够更准确地评估系统在不同负载模式下的表现。
同步定时器：用于创建集合点，使得多个线程在同一时刻执行特定的操作，以此来制造峰值负载或检验系统的瞬时响应能力。
网络环境
网络带宽：即使是在局域网内，有限的带宽也可能限制JMeter向目标服务器发送请求的速度。尤其是在广域网环境中，网络状况更加复杂多变，可能会影响到测试结果的真实性。
网络延迟：高延迟会延长请求和响应的时间，从而影响到平均响应时间和吞吐量等关键指标。此外，网络抖动也会对测试稳定性造成干扰。
数据传输协议：不同的协议（如HTTP/HTTPS、TCP、UDP等）有着各自的特性，在选择适合的协议进行测试时需要考虑其对性能的影响。
测试设计
接口参数化：对于动态内容丰富的API接口来说，采用随机化的参数值来进行压测是非常必要的。这样可以确保覆盖更多场景，同时也能更好地模拟实际生产环境中的流量特征。
测试场景多样性：单一场景下的测试结果往往不足以全面反映系统的性能状况。因此，构建包含多种业务流程的复合型测试用例是十分重要的，比如将登录、浏览商品详情页、加入购物车等一系列操作组合起来进行综合评测。
持续时间：短期测试只能揭示短期内的表现，而长期疲劳测试则有助于发现潜在的问题，如内存泄漏、数据库连接池耗尽等。
被测系统配置
服务器硬件资源：包括但不限于CPU核心数、内存大小、磁盘读写速度等。充足的硬件资源是支撑高强度负载的基础条件之一。
应用程序代码质量：高效的算法实现、合理的架构设计、良好的编码习惯都能显著提升系统的处理效率，反之亦然。
数据库优化：如SQL语句优化、索引建立、表结构设计等都会直接影响到查询性能。特别是在高并发情况下，未经优化的数据访问可能会成为性能瓶颈。
在利用JMeter进行性能测试时，为了得到准确可靠的测试结果，必须综合考虑上述各个方面的因素，并尽可能地控制变量以减少外部干扰。例如，可以通过调整JMeter的配置参数来模拟不同的负载模式，同时也要注意监控被测系统的各项性能指标变化趋势，以便及时发现问题并采取相应措施加以改进。此外，保持测试环境的一致性和可控性也是确保测试结果具有可比性和参考价值的重要前提。
阅读后若有收获，不吝关注，分享，在看等操作！！！