Ubuntu 上 JMeter 性能评估与提升
总体结论
在 Ubuntu 上，JMeter 作为纯 Java 的负载生成器，性能主要受 JVM 堆与 GC、网络与内核参数、测试计划设计 以及 是否使用分布式 影响。非 GUI 模式、合理的堆与 GC 配置、连接复用与超时控制，通常能在普通服务器上稳定支撑从数百到数千并发线程的 HTTP 压测；当单机线程与 RPS 需求继续上探时，通过 分布式压测 横向扩展是更稳妥的路径。
影响性能的关键因素
- JVM 堆与 GC：默认堆往往偏小，压测易出现 OutOfMemoryError 或 长 STW 停顿；合理设置 -Xms/-Xmx 并选择 G1/ZGC/Shenandoah 可显著降低停顿、提升稳定性。堆过大也会拉长 GC 周期，反而影响负载生成能力。建议将堆的最高占用率控制在最大堆的 70% 以下，平均占用维持在 40%–70%。
- 网络与内核：短连接/握手过多会受 TIME_WAIT 与端口耗尽影响；启用 Keep-Alive、复用连接、适度调优内核网络参数（如 somaxconn、tcp_tw_reuse）有助于提升 RPS 与稳定性。
- 测试计划与监听器：使用 View Results Tree 等监听器会显著增加内存与 I/O；压测时应关闭或改为 Aggregate Report/Summary Report，并减少不必要的 响应体保存 与高开销配置（如盲目“抓取所有嵌入资源”）。
- 分布式扩展：当单机难以达到目标并发/RPS 时，采用 Controller/Worker 分布式架构，把压力分散到多台 Ubuntu 负载机，可线性扩展压力生成能力。
快速自测与瓶颈定位
- 基线测试：在 Ubuntu 上使用非 GUI 运行 JMeter，快速得到吞吐与响应基线。示例：
/bin/jmeter -n -t test.jmx -l result.jtl；同时用 top/htop、free -m、df -h、iftop 观察 CPU、内存、磁盘与网络是否成为瓶颈。
- 服务端监控：在被测服务器（如 Tomcat/JSP）启用 JMX 或使用 VisualVM/JMC 观察 CPU、堆、线程；结合 JMeter 插件 PerfMon Metrics Collector 与 ServerAgent 采集被测机的 CPU/内存/磁盘/网络，定位是“压测机瓶颈”还是“被测系统瓶颈”。
- 结果判读：关注 Throughput（TPS/QPS）、Average/95th/99th 响应时间、Error%；若吞吐不再随并发上升、响应时间陡增，通常意味着接近系统瓶颈或资源限制。
实用优化清单
- 运行模式：压测一律使用 非 GUI 模式（
-n），减少资源占用与结果 I/O 开销。
- JVM 参数：在
jmeter.sh 中设置合适的堆与 GC，例如：HEAP="-Xms4g -Xmx4g"（建议 Xms=Xmx 减少堆伸缩抖动），并选择低停顿 GC（如 -XX:+UseG1GC；在支持的 JDK 上可评估 ZGC/Shenandoah）。
- HTTP 客户端：使用 HttpClient4 实现；开启 Keep-Alive；设置合理超时（如 Connect=5000 ms、Response=10000 ms）；降低失败重试（如 retry=1）以避免“虚高”错误请求；必要时设置连接存活时间（如 httpclient4.time_to_live=60000）。
- 结果输出：压测时关闭保存响应体（
jmeter.save.saveservice.response_data=false），仅保留必要字段；提高控制台摘要频率（summariser.interval=10）便于观察；报告阶段再用聚合监听器与 HTML 报告生成。
- 分布式压测：准备多台 Ubuntu Worker，先启动
jmeter-server 并正确设置 java.rmi.server.hostname，再由 Controller 统一下发测试，显著扩展压力上限。
