JMeter发送2MB JSON POST请求内存消耗过高的优化咨询

嘿，针对你遇到的JMeter HTTP采样器内存占用高、想提升单JVM吞吐量的问题，我整理了几个原生HTTP采样器范围内的优化方案，不用依赖外部CURL，你可以逐一试试：

1. 全局复用请求体，避免重复加载 #

你现在用__StringFromFile每次请求都读取2MB JSON，本质上每个线程每次请求都会创建新的字符串实例，内存里会有大量重复内容。可以改成一次性预加载请求体到全局属性，让所有线程共享同一个实例：

• 添加一个Setup Thread Group（仅在测试启动时运行一次），里面放JSR223 Sampler，用Groovy代码读取JSON并存储到全局属性：

  // 替换为你的JSON文件实际路径
  def payloadFile = new File("/Users/xxx/payload.json")
  def payloadContent = payloadFile.text
  // 存入全局属性，所有线程共享
  props.put("GLOBAL_JSON_PAYLOAD", payloadContent)
  

• 然后在HTTP采样器的请求体里引用这个全局属性：${__P(GLOBAL_JSON_PAYLOAD,)}

这样所有线程复用同一个字符串对象，能大幅减少内存重复占用——毕竟2MB的内容重复几十次的话，内存开销会直线上升。

2. 裁剪HTTP采样器的不必要功能 #

JMeter的HTTP采样器默认开启了一些可能没用的功能，会额外消耗内存：

• 关闭Retrieve All Embedded Resources：如果你不需要请求页面内的静态资源，这个选项会发起额外请求，浪费内存和CPU。
• 关闭Save Response as MD5 Hash（如果不需要）：默认会计算响应的MD5，但如果你的测试不验证响应完整性，这个步骤可以省掉。
• 禁用Save Response Data：在jmeter.properties里把jmeter.save.saveservice.response_data设为false，如果不需要保存完整响应的话，大响应会吃掉大量内存和磁盘空间。

3. 优化JVM参数，强化G1GC的表现 #

你已经用了8GB堆和G1GC，再加上这些参数能进一步提升内存效率和吞吐量：

• 添加-XX:+UseStringDeduplication：G1GC的字符串去重功能，自动合并内存中重复的字符串实例，对大量复用请求体的场景非常有用。
• 固定堆大小：把-Xms和-Xmx都设为8GB（-Xms8g -Xmx8g），避免JVM动态调整堆的开销。
• 控制GC暂停时间：添加-XX:MaxGCPauseMillis=200，让G1GC尽量把停顿时间控制在200ms内，减少对吞吐量的影响。
• 并行处理引用：添加-XX:+ParallelRefProcEnabled，加快GC时的引用处理速度。

4. 用JSR223 Sampler替代原生HTTP采样器（更灵活的内存控制） #

如果原生HTTP采样器的开销还是太大，可以用Groovy直接发送HTTP请求，自己控制请求体的复用和资源释放：

• 在JSR223 Sampler里用OkHttpClient发送请求，示例代码：

  @Grab('com.squareup.okhttp3:okhttp:4.10.0')
  import okhttp3.*
  
  // 复用全局请求体
  def payload = props.get("GLOBAL_JSON_PAYLOAD")
  def client = OkHttpClient.newBuilder()
    .connectionPool(new ConnectionPool(50, 5, TimeUnit.MINUTES)) // 自定义连接池配置
    .build()
  
  def request = new Request.Builder()
    .url("https://your-target-api.com/endpoint")
    .post(RequestBody.create(payload, MediaType.get("application/json")))
    .addHeader("Content-Type", "application/json")
    .build()
  
  def response = client.newCall(request).execute()
  // 设置采样器结果，兼容JMeter的报告逻辑
  prev.setResponseCode(response.code().toString())
  prev.setResponseMessage(response.message())
  prev.setResponseData(response.body().bytes())
  response.close()
  

  这种方式可以更精细地控制连接复用和内存使用，Groovy的性能和原生Java接近，比JMeter内置采样器的开销更低。

5. 压缩请求体（如果服务器支持） #

如果你的目标服务器支持Gzip压缩的请求体，可以把JSON压缩后再发送，内存里存储的就是压缩后的内容（2MB JSON压缩后通常只有几百KB）：

• 在Setup Thread Group的JSR223 Sampler里预压缩请求体：

  def payloadFile = new File("/Users/xxx/payload.json")
  def payloadBytes = payloadFile.bytes
  
  // Gzip压缩
  def baos = new ByteArrayOutputStream()
  def gzip = new java.util.zip.GZIPOutputStream(baos)
  gzip.write(payloadBytes)
  gzip.close()
  def compressedPayload = baos.toByteArray()
  
  props.put("COMPRESSED_PAYLOAD", compressedPayload)
  

• 在HTTP采样器里：
  • 请求体选择“Use Raw Bytes”，然后引用${__P(COMPRESSED_PAYLOAD,)}
  • 在HTTP Header Manager添加Content-Encoding: gzip头

这样内存占用会大幅降低，同时也减少了网络传输时间，间接提升吞吐量。

6. 优化JSON断言的性能 #

内置的JSON Assertion在处理大响应时会有额外开销，换成JSR223 Assertion用Groovy解析JSON更高效：

• 替换JSON Assertion为JSR223 Assertion，代码示例：

  def response = prev.getResponseDataAsString()
  def json = new groovy.json.JsonSlurper().parseText(response)
  // 只检查关键字段，避免解析整个大JSON的不必要开销
  assert json.code == 200 : "Expected response code 200, got ${json.code}"
  

  Groovy的JsonSlurper比JMeter内置的JSON解析器更快，而且你可以只解析需要验证的字段，减少内存和CPU消耗。

这些方案都是在JMeter原生组件范围内实现的，不需要依赖外部工具，应该能帮你在8GB堆内存的配置下提升单JVM的吞吐量，同时降低内存占用。

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