我为自己的分布式事务管理器写了压测脚本，本来以为是半天的活。

结果前三版的结论全是错的。不是代码有 bug，而是压测脚本一直在测自己。

这篇记录那三次翻车，还有修完之后看到的真实瓶颈——它跟我一开始的假设正好相反。

第一次的观点是，卡在 笔/秒，纹丝不动

第一版压测跑出来：不管协调器开几个推进 worker。端到端吞吐都是 笔/秒 个 worker 是它，个还是它。

"并行没生效"是最自然的解释。我去查了抢占逻辑、查了连接池、查了锁——都没问题。

真正的线索在完成曲线里：

t= .36s done= t= .86s done= t= .36s done= t= .86s done= 

每 500ms 正好 笔，一次不多一次不少。 真实程序不会这么整齐。这种刻度感只可能来自某个固定的时间常数。

笔/500ms = 笔/秒。每个 worker 笔/秒，也就是每笔事务 83ms。而一笔事务要调两次业务接口。

/ ≈ 40ms。

40ms 是 Linux 延迟 ACK 的典型值。

• Nagle 算法导致第二段数据等待对端 ACK 才能发送；
• class Busi: disable_nagle_algorithm = True # 就这一行

改完这方面。 笔/秒，倍。

真实业务服务默认就是 TCP_NODELAY,所以这纯粹是压测脚本的伪影。不修的话，等于给被测程序栽赃。

再看第二次。压测客户端自己顶到了天花板

修完 Nagle，我开始比较两种事务模式：SAGA和二阶段消息。

结果二阶段消息慢 %。看起来很合理——多一次往返嘛。

差点就这么写进文档了。临时做了个对照实验：让压测客户端去打协调器的 /health,一个什么都不做的端点。

并发 : req/s并发 : req/s并发 : req/s

• <~ req/s，跟并发数无关.
• This is Python GIL ceiling,not measured system.
• SAGA 那组测出来是 笔/秒 = req/s；二阶段消息是 笔/秒 = **req/s** ——两边都撞在客户端上限，“慢 %”完全是假象.
• Pushing commit side to multi-process 后 SAGA 提交阶段从 涨到 **笔/秒**.
• This is same error second time: business service。completion judgment,commit side all single-process Python;fixed first two but still wrong.
• If you fix this part you might think you're done.

第三次这方面，某几行结果凭空消失

• Patching coordinator port range issue leads to “Address already in use” even though port seems free via ss.
• The chosen port fell into kernel's dynamic range;client connections randomly assigned that local port cannot bind for listening.
• This only surfaces under high churn;connection pool clients rarely hit it while new connections trigger immediately.
• Migrating port from X to Y resolves issue.

拿 DTM 做对照，第一次结论完全反了

• I pulled DTM v1 up on same machine,same Redis,same business service and same bench client.
• The first round shows DTM **笔/秒** vs my implementation **X**.
• This looks suspiciously good—look at DTM logs and see many “connection reset by peer.”

• class ThreadingHTTPServer:
  request_queue_size = # socketserver 默认值
  # Accept queue only X
  # If client doesn't reuse connections,# queue gets full → kernel RST.
  

No connection pooling on DTM → queue saturates → RST errors appear when load high. This explains *** throughput differences are mainly due to client connection reuse strategy rar than transaction coordination logic. Fixing DTM's request_queue_size gives ~X% improvement. I almost published a “fast X‑times” claim. Use this as cautionary example that misinterpreting script behavior can lead you astray. \t\t\t\t\t\t \t\t\t\t \t guided by actual logs. " rust request_queue_size = Then I did:
• Add request_queue_size bigger
• Ensure max_open_files increased

Result的观点是。Dtmrs becomes 笔/秒,zero errors—10× faster than before.*

---

修完之后这方面，真正瓶颈跟想法相反

User Pain Point:

* Inadequate concurrency in client scripts leads to overestimating system capacity. * Single-threaded backends cause misleading CPU saturation metrics if you only count command numbers. * Misconfigured network ports can silently drop tests due to OS-level conflicts. * Overlooking client-side GIL limits can make transaction coordination appear slower than it truly is. * Lack of proper benchmarking sanity checks results in wasted optimization cycles.

### What do developers usually get wrong?

1. They assume higher throughput automatically means fewer commands executed per transaction.
2. They treat command count as sole indicator of bottleneck without considering round‑trip overhead.
3. They forget that each network hop incurs fixed latency regardless of command volume.
4. They overlook system limits like max_open_files or TCP backlog affecting throughput.
5. They rely on unverified baseline tests . All se assumptions may lead m astray.

---

原文重排与细节

html

原始内容重排

---

使用者痛点

1. 脚本误导 压测工具往往隐藏自身瓶颈。例如未开启 Nagle 或未使用连接池，会把“自身限速”误认为程序问题。

2. Python GIL 限制 单进程 Python 在高并发下受 GIL 限制，使得吞吐量与实际服务器无关。

3. 端口冲突与动态分配 动态端口范围与应用监听冲突导致随机报错，却难以通过常规日志发现。

4. 网络回路固定成本 每条命令虽少。但每次往返都会产生协议解析、程序调用等固定开销，需要从往返次数而非命令数衡量。

5. 缺乏基线检查 未先验证测试环境和工具是否正常运行，即可把错误归咎于被测程序。

---

项目信息

说到项目名，dtmrs 语言这方面，Rust 至于支持模式，SAGA / TCC / 二阶段消息 / XA / workflow 再看存储后端可选。sqlite / Postgres / MySQL / Redis

功能这方面，

• 协调器可以直接嵌入到业务进程中；分支直接在同一进程内执行，无需单独部署服务。其实，
• C ABI 接口支持 Python / Node / JVM 调用。
• 与 Go 在共享运行时方面存在差异。

压测脚本位于 /bench/bench.py。请先阅读文件头注释中的三条前置检查，以避免误将脚本错误当作程序性能问题。