如何在JMeter中提升TPS至2000？已尝试多种方法仍存差距

• 优化测试脚本

  • 移除不必要的元件：禁用或删除调试用的查看结果树、断言结果等监听器，这些会消耗大量资源。
  • 替换低效元件：用CSV Data Set Config替代自定义函数读取外部数据，避免重复IO操作；用JSR223 Sampler替代BeanShell Sampler，前者性能更高。
  • 合并重复请求：如果业务允许，把多个小请求合并成一个批量请求，减少JMeter的线程调度开销。

• 调整采样器配置

  • 关闭响应数据保存：在HTTP请求采样器中，取消勾选“保存响应数据”和“保存响应头”，除非必须验证响应内容。
  • 启用HTTP连接复用：在HTTP请求默认值里设置“连接保持”为true，复用TCP连接，减少握手开销。

• 系统层面优化

  • 调整操作系统参数：增大文件描述符限制（执行ulimit -n 65535），优化TCP参数（比如开启tcp_tw_reuse、tcp_tw_recycle，具体根据操作系统调整），减少TIME_WAIT状态的连接数量。
  • 优化JVM参数：除了堆内存，改用-XX:+UseG1GC垃圾回收器，减少GC停顿时间；设置-XX:MaxMetaspaceSize避免元空间溢出。

• 调整负载模式

  • 阶梯式加压：不要一次性启动所有线程，分阶段逐步增加线程数，给系统缓冲时间，避免瞬间负载导致的性能瓶颈。
  • 随机思考时间：把固定思考时间改成随机范围（比如100-500ms），更贴近真实用户行为，同时避免线程同步等待引发的TPS波动。

• 优化断言与后置处理器

  • 精简断言数量：只保留关键业务逻辑的断言，别对每个请求都做全量响应断言。
  • 使用高效断言：用Response Assertion替代自定义JSR223断言，前者性能损耗更低；如果必须用脚本断言，尽量简化逻辑，避免复杂计算。

• 分布式测试进阶优化

  • 统一slave节点配置：确保所有slave的JMeter版本、JVM参数、操作系统参数完全一致，避免节点间性能差异。
  • 禁用slave本地监听器：所有监听器只在master节点启用，减少slave的资源消耗。
  • 按需分配线程：根据每个slave节点的性能，分配对应数量的线程，避免资源闲置或过载。

• 定位瓶颈根源

  • 实时监控指标：用JMeter的Backend Listener配合监控工具，实时跟踪JMeter的线程状态、CPU、内存、GC情况，以及被测系统的性能数据，找到具体瓶颈点。
  • 检查被测系统负载：如果JMeter自身资源还没跑满，大概率是被测系统的问题，需要优化后端服务（比如数据库查询、接口逻辑等）。

内容的提问来源于stack exchange，提问作者Nikhil