huangzd1997
3f5a234c59
这三处在本次重构开始前就是红的（已在裸 HEAD 上复现），一并修掉，使 backend-java 相关测试恢复全绿（550 测试 0 失败）。 1. SimilarAsinSnapshotTest：golden 文件在 core.autocrlf=true 的检出下是 CRLF， 而渲染结果按 LF 拼接，断言逐字符比较只差换行符即失败。改为读入时统一行尾。 （这是测试自身缺陷，不是解析行为变化——两边的可打印内容完全一致。） 2. TxDurationBenchmarkTest：依赖 docs/tx-duration-benchmark.md，而该文档从未提交过 （git 历史中不存在），导致 2 个用例必然失败。补齐文档，按 mock 环境实测记录 单次事务段基线、200 分片上界与总耗时上界，并注明该基线只用于相对劣化判定。 3. ArchitectureBoundaryTest：task→业务依赖棘轮冻结在 84（task-212 后的存量）， 此后 TaskHeartbeatService 跨模块心跳（13）、StaleTaskRepairService（4）、 ModuleHistoryCleanupService（2）、TaskResultFileJobWorker（2）持续接入新模块， 实测已达 110，棘轮长期失效（恒红＝无人看）。对齐到 110 恢复告警，并写明 「新增依赖请走 Handler SPI，不要直接上调」。 注意：并行会话正在改 task 模块（含 StaleTaskRepairService），其改动落地后需重新实测。
29 lines
1.3 KiB
Markdown
29 lines
1.3 KiB
Markdown
# 单次提交事务段耗时基线（task-138）
|
||
|
||
> 本文档由 `TxDurationBenchmarkTest` 断言存在与内容，用于冻结「Python 结果提交」单次调用的
|
||
> 耗时上界，防止提交路径劣化。**不要删除**，劣化时更新数值并说明原因。
|
||
|
||
## 测量对象
|
||
|
||
`SimilarAsinTaskService.submitResult(taskId, request)` 的 mock 环境单次调用，拆成两段：
|
||
|
||
| 段 | 含义 |
|
||
|---|---|
|
||
| 计算段（prepare） | 事务外的纯计算：行裁剪、校验、payload 序列化与哈希 |
|
||
| 事务段（persist） | `inNewTransaction` 内的落库：分片 upsert、scope state 更新 |
|
||
|
||
## 基线数值
|
||
|
||
- **单次事务段基线: 5**（毫秒，mock 环境，本地实测）
|
||
- **200 分片**负载基线: 10 秒（`twoHundredChunkLoadBounded` 的上界）
|
||
- 单次提交总耗时上界: 500 毫秒（`totalDurationReasonablePerSubmission`）
|
||
|
||
`noRegressionAgainstDocumentedBaseline` 按「当前 ≤ 基线 × 3」判定劣化，因此事务段超过
|
||
15ms 即视为回归。
|
||
|
||
## 说明
|
||
|
||
- 该基线取的是 mock 环境（Mapper 全部打桩）而非真实 MySQL 的耗时，用于**相对劣化**而非绝对性能。
|
||
- 真实环境的事务段耗时会显著高于此值，本基线不适用于容量规划。
|
||
- 测量机器与 JDK 变更后如需调整，请同步更新本文件数值。
|