JMeter标准MongoDB Sampler不支持事务压测，因其每次请求新建连接、无session复用机制，无法维持事务上下文；必须用JSR223 Sampler配合MongoDB Java Driver手动管理ClientSession实现start/commit/abort全流程。
JMeter 本身不原生支持 MongoDB 事务（session.startTransaction()、session.commitTransaction()），直接用 MongoDB Database Sampler 或 JDBC 取样器无法构造带事务上下文的请求；必须通过自定义 Java 请求或 JSR223 + MongoDB Java Driver 手动管理会话与事务控制流。
为什么不能用标准 MongoDB Sampler 做事务压测
标准 MongoDB Database Sampler（JMeter 插件）只封装了单条 CRUD 操作，内部无会话生命周期管理，所有操作默认在无事务上下文中执行。即使你写入 session.startTransaction() 这类语句，驱动也会抛出 IllegalStateException: Session is not in transaction —— 因为 sampler 每次调用都新建连接、无 session 复用机制。
- 它不维护
MongoClient实例的复用，每次取样都 new 一个新 client，开销大且无法跨操作共享 session - 不支持显式
commit/abort控制，无法模拟事务失败回滚路径 - 无法设置事务级别（如
ReadConcern.MAJORITY、WriteConcern.W2）
用 JSR223 Sampler + MongoDB Java Driver 实现事务压测
这是目前最轻量、可调试、易集成的方案。需手动引入 mongodb-driver-sync（v4.11+ 推荐，兼容 MongoDB 6.x / 7.x），并确保 driver jar 放入 JMETER_HOME/lib/ 目录下（重启 JMeter 生效）。
-
MongoClient必须作为全局变量复用（例如存入props或vars），否则每笔事务新建连接，压测结果失真 - 事务必须在同一个
ClientSession内完成：start → ops → commit/abort，不可跨 sampler 执行 - 示例关键代码片段（Groovy，JSR223 Sampler 中）：
import com.mongodb.client.MongoClients
import com.mongodb.client.MongoClient
import com.mongodb.client.ClientSession
import com.mongodb.client.MongoCollection
import com.mongodb.client.MongoDatabase
import org.bson.Document
import static com.mongodb.client.model.Filters.*
import static com.mongodb.client.model.Updates.*
<p>// 复用 client（首次初始化后存入 props）
def client = props.get("mongoClient")
if (!client) {
client = MongoClients.create("mongodb://localhost:27017/?maxPoolSize=200")
props.put("mongoClient", client)
}</p><p>def database = client.getDatabase("testdb")
def collection = database.getCollection("orders")</p><p>def session = client.startSession()
try {
session.startTransaction()
collection.insertOne(session, new Document("orderNo", "T" + System.nanoTime()), null)
collection.updateOne(session, eq("orderNo", "T" + System.nanoTime()), set("status", "paid"))
session.commitTransaction()
vars.put("txn_result", "success")
} catch (Exception e) {
session.abortTransaction()
vars.put("txn_result", "failed: " + e.getClass().getSimpleName())
} finally {
session.close()
}线程组与参数配置的关键陷阱
事务压测对连接池、会话数、超时设置极度敏感。以下配置不调优，极易出现 ConnectionPoolMaxSizeReachedException 或事务卡死。
-
Ramp-Up Period必须 ≥ 10 秒（哪怕只有 50 线程）：避免瞬间建 session 淹没 MongoDB 的maxConns -
Thread Group中勾选Same user on each iteration?：保证同一虚拟用户复用 session（需配合 Groovy 中的 session 缓存逻辑） - 在
MongoClientURI 中显式指定连接池参数：mongodb://localhost:27017/?maxPoolSize=200&minPoolSize=20&maxConnectionLifeTimeMS=600000 - 务必设置
serverSelectionTimeoutMS=5000和socketTimeoutMS=30000，防止事务阻塞拖垮整个线程组
如何验证事务是否真实生效
仅看响应码或日志成功不等于事务真正提交。必须从 MongoDB 侧交叉验证：
- 开启 MongoDB 日志（
logLevel: 1+verbosity: {transaction: 2}），观察transaction字段是否包含"type":"commit"或"type":"abort" - 在另一个 shell 中执行
db.currentOp({"secs_running": {"$gt": 5}})，确认长事务未堆积 - 压测中随机抽样查询刚插入的文档：
db.orders.find({orderNo: /^T\d{19}/}).count()，对比预期数量与实际落库数量 - 故意在事务中间 throw 异常，检查对应文档是否从未写入集合（验证 abort 隔离性）
事务压测最易被忽略的是「会话生命周期」和「连接池饥饿」——它们不会立刻报错，但会让 P95 响应时间毛刺剧烈、错误率在高并发后期陡增。务必在 100 并发下先跑 2 分钟预热，再开监控看 mongostat 的 netIn/netOut 和 conn 变化趋势。
