7.2 性能调优策略

7.2 性能调优策略

本节摘要：JMeter 自己也要调优，否则它先成瓶颈。本节讲 JVM 调优、减少内存占用、用非 GUI 模式——让 JMeter 跑得更稳更大。

核心问题

阅读完本节，你应当能够：

1. 调 JMeter 的 JVM
2. 减少内存占用
3. 优化执行方式

概念脉络

一、为什么 JMeter 自己要调优

JMeter 模拟大量并发，自己也要消耗资源。不调优时 JMeter 自己先 OOM 或 CPU 打满，测出来的是 JMeter 性能不是被测系统。调优让 JMeter 跑得更稳，才能压出真实结果。

二、JVM 调优

图 7-2 JMeter 自身调优

# jmeter.bat 或 jmeter.sh 调 JVM
set HEAP=-Xms4g -Xmx4g
set GC_ALGO=-XX:+UseG1GC -XX:MaxGCPauseMillis=100
​

三、减少内存占用

• 关结果树：压测时关，调试时开
• 少用监听器：只留简单数据写入存文件，聚合报告可看但不存
• 简单数据写入：直接写 JTL/CSV，比图形监听器省内存
• Backend Listener：推外部系统，不在 JMeter 存

四、非 GUI 模式

jmeter -n -t test.jmx -l result.jtl -e -o report/
​

非 GUI 不加载图形界面，省内存、结果更准。正式压测必用。

五、脚本优化

• Beanshell 换 Groovy（JSR223），性能好
• 避免在循环里做重计算
• 提取器用 JSON 提取器比正则快

六、分布式兜底

单机调到极限还扛不住，用分布式分负载，别硬撑导致 JMeter 崩。

⚠️ 常见坑：GUI 模式开结果树跑大压测——GUI 占内存、结果树存每个请求，高并发 OOM。正式压测用非 GUI、关结果树。

💡 关键直觉：JMeter 自己也要调优——JVM 堆调大、关调试元件、非 GUI 模式、Groovy 替代 Beanshell、扛不住用分布式。JMeter 不成瓶颈才能压出真实结果。

本节速览

• JVM 调优：堆调大（4G-8G）、G1GC，按机器内存。
• 减内存：关结果树、少监听器、简单数据写入、Backend 推外部。
• 非 GUI 模式：jmeter -n，省内存结果准，正式压测必用。
• 脚本优化：Groovy 替代 Beanshell、避免循环重计算、JSON 提取器。
• 分布式兜底：单机扛不住用分布式，别硬撑。

下一节讲安全合规——压测的规矩。

调优方向

JMeter 性能调优分两个层面：压测机调优（保证压测机不成为瓶颈）与脚本调优（减少无效开销）。压测机调优：增大 JVM 堆、优化 GC、提高文件句柄与端口范围；脚本调优：减少断言开销、用 JSR223 代替 Beanshell、关闭不必要监听器、结果流式写入。

调优优先级表

调优验证

每次调优后必须验证效果：对比调优前后压测机 CPU/内存占用与最大并发能力；确认结果一致性（调优不应改变被测系统表现，只提升压测能力）。调优的目标是让压测机"退后"，使测量结果真实反映被测系统性能，而不是让压测机抢戏。

调优实践步骤

JMeter 调优的实操步骤：先用 CLI 模式跑一个基准脚本，记录压测机 CPU/内存基线；关闭 GUI 相关监听器（用 Simple Data Writer 替代图形监听器）；启用结果流式写入；脚本中 JSR223 采样器勾选编译缓存；调大 JVM 堆并观察 GC 频率。每一步调优后对比压测机资源占用与并发能力，量化收益，保留效果显著的调整。

常见调优误区

调优误区提醒：盲目调大堆内存（过大导致 GC 时间更长）；在 GUI 模式下做正式压测（界面开销干扰结果）；堆叠过多监听器（拖慢执行）；忽略脚本本身的低效（如大量正则提取）。调优目标永远是让压测机"隐形"，任何让压测机成为瓶颈的因素都应优先消除。

脚本层面的深度调优：减少正则提取（改用 JSON 提取）；采样器间复用连接（HTTP 请求默认值开启 keep-alive）；禁用无用的配置元件（作用域内未使用的变量）；监听器精简（只留聚合报告与必要图表）；采样器重试与超时设置合理。脚本调优收益往往大于 JVM 调优，值得优先投入。

调优与结果的关系

调优必须守住底线：调优不能改变被测系统的负载特性（线程数、请求频率、数据分布应保持一致），否则对比无意义。每次调优只改一个变量，对比前后结果确认无副作用，再继续下一步。

总结：性能调优的目标是让压测机回归工具本分，真实反映被测系统性能。从脚本优化到 JVM 调优逐层推进，每次只改一个变量并验证效果，是稳妥高效的调优路径。