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），其改动落地后需重新实测。
1.3 KiB
1.3 KiB
单次提交事务段耗时基线（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 变更后如需调整，请同步更新本文件数值。