JMeter压测吞吐量未达标：配置40QPS仅达10-12QPS求助

测试计划结构 #

Test Plan
—Thread Group (线程数=40，Ramp-Up周期=20秒，循环次数=250)
     —— Directory Listing Data source（指定源目录，取消勾选所有复选框）
     —— Post API HTTP Request，请求体为${fileContent}
           —— Post API Header Manager，其中一个请求头为Authorization，硬编码令牌为Bearer <token>
           —— JSR223 PreProcessor，用于从Directory Listing Data source读取数据
     —— Constant Throughput Timer，目标吞吐量为2400请求/分钟（即40请求/秒），基于当前线程组所有活跃线程计算吞吐量

文件准备 #

桌面存在名为ten的文件夹，包含10000个txt文件，命名格式如1a.txt、2a.txt等。

JSR223 PreProcessor代码 #

import org.apache.jmeter.services.FileServer
import java.util.concurrent.TimeUnit

// Get the filename
def file = vars.get("filename")

// Skip unwanted files
if (file == ".DS_Store" || !file.endsWith(".txt")) {
    return
}

def path = "/Users/username/Desktop/ten/" + file
def fileContent = new File(path).text

// Log the file being posted
log.info("Thread " + ctx.getThreadNum() + " is posting file: " + file)

// Save the file content to a variable
vars.put("fileContent", fileContent)

// Save the start time
long startTime = System.nanoTime()
vars.put("startTime", startTime.toString())
vars.put("fileName", file)

核心配置参数 #

线程组设置 #

• 线程数：40
• Ramp-Up周期：20秒
• 循环次数：250

Constant Throughput Timer设置 #

• 目标吞吐量：2400请求/分钟（40请求/秒）
• 吞吐量计算依据：当前线程组所有活跃线程

总请求数：10000（40线程×250循环） #

预期与实际行为 #

• 预期：达到40请求/秒的吞吐量
• 实际：仅能达到10-12请求/秒

排查与解决建议 #

1. 文件读取性能瓶颈 #

当前JSR223脚本用new File(path).text同步读取文件，40线程并发读取时，磁盘IO易成为瓶颈（尤其是机械硬盘）。

• 优化方案：
  • 改用JMeter内置__FileToString函数，直接在请求体中写${__FileToString(/Users/username/Desktop/ten/${filename},,)}，移除PreProcessor里的文件读取逻辑，该函数性能优于自定义Groovy代码。
  • 若保留脚本读取，用缓冲流提升效率：

    def fileContent = new File(path).newReader().withReader { reader ->
        reader.text
    }
    

  • 若文件总大小在内存承受范围内，提前把所有文件内容加载到全局变量，避免重复磁盘IO。

2. Constant Throughput Timer配置调整 #

选择“基于当前线程组所有活跃线程”的计算模式，Ramp-Up阶段（前20秒）线程未完全启动时会限制吞吐量；线程因文件读取阻塞时，活跃线程数不足也会拖慢速率。

• 优化方案：
  • 将计算依据改为“基于所有活跃线程（包括其他线程组）”，或尝试“基于每个线程”模式（需调整单线程目标吞吐量为1请求/秒，40线程总计40请求/秒）。
  • 替换为Throughput Shaping Timer，该组件可灵活控制吞吐量曲线，适配Ramp-Up过程。

3. 数据源与线程循环匹配检查 #

确认Directory Listing Data Source配置：

• 是否设置为“循环读取”所有文件，避免线程因等待新文件阻塞。
• 检查文件过滤逻辑，确保10000个txt文件都能被正确遍历。

4. JMeter自身性能优化 #

• 调整堆内存：编辑jmeter.sh（Mac/Linux）或jmeter.bat（Windows），修改堆内存参数为HEAP="-Xms2g -Xmx2g"（根据电脑内存调整，建议分配总内存的1/4~1/2），避免内存不足导致频繁GC。
• 精简监听器：关闭“查看结果树”等实时监听器，仅保留“聚合报告”必要组件，减少资源消耗。
• 优化JSR223脚本：确保选择Groovy语言，勾选“Compile script if possible”选项，启用脚本编译提升执行效率。

5. 后端系统瓶颈排查 #

若以上优化后吞吐量仍未达标，检查后端API性能：

• 监控后端服务器CPU、内存、磁盘IO、数据库连接数等指标，确认是否存在资源瓶颈。
• 查看API响应时间，若单请求响应时间超过1秒，40线程的理论最大吞吐量会被拉低，需优化后端服务性能。

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