docs: record tenant batching capacity results

2026-08-25 18:10:37 +08:00
parent b5005f21d5
commit b1e297245c
4 changed files with 27 additions and 1 deletions
@@ -513,3 +513,17 @@ API 必须返回逐事件结果，而不是只有整批成功或失败：
 本轮只在单Gateway架构内处理95 TPS定向诊断暴露的工作流问题，不实施多Gateway P2。具体改造为：领取前最多等待40ms把小批合并到目标32条；按企业分组，不同企业并行、同企业各批串行；领取SQL排除正在执行的企业；Submit Outbox及关联消息的原生SQL时间统一为UTC。环境参数必须显式配置并由发布脚本校验，目标批量不得超过实际批次上限。

 发布验收保持应用单价325以及现有临时号段规则和白名单。先做单企业100/150 TPS，以确认原约95 TPS边界是否改善；再使用至少两个独立企业做聚合200 TPS，用于区分单企业账户一致性边界和平台总吞吐。所有档位都按非补发首次供应商Submit计算，并对账Submit、回执、上行、账务、主备补发、拦截规则与队列排空；停止条件沿用第五阶段，不以入口SubmitResp替代完整链路结论。
+
+## 16. 单企业微批与双企业并行实测结果
+
+本轮提交`76e7c8c`实现按企业分组、有界40ms聚合、同企业串行/跨企业并行和Outbox UTC；压测中先后暴露两个独立连接问题：Node默认keep-alive短于Gateway连接池导致2条loopback reset/Result 9，提交`394949f`将API keep-alive/headers timeout固定为120/125秒；同一connectionId的connected/submit并发回调被误计为第二条连接，提交`b5005f2`改为同连接豁免且首次状态幂等upsert。每次修复均重新备份、发布和从100 TPS重测，多Gateway P2始终未实施。
+
+| 场景 | 客户入口 | P50/P95/P99 | Inbox微批 | 非补发首次供应商Submit | 结论 |
+|---|---:|---:|---:|---:|---|
+| 单企业100 TPS | 999/999，全0 | 72/243/466ms | 23批，平均43.43、最大64，10.721秒排空 | 999条/10.423秒=`95.85 TPS` | 入口完整，完整链接近100 |
+| 单企业150 TPS冲击 | 1498/1498，全0 | 53/83/117ms | 33批，平均45.39、最大64，12.453秒排空 | 1498条/12.192秒=`122.87 TPS` | 新单企业短窗上限约123，未达150 |
+| 双企业合计200 TPS冲击 | 1999/1999，全0 | 80/148/287ms | 两企业各22批，平均44.55/46.32 | 1999条/15.449秒=`129.39 TPS`；两企业64.69/65.96 | 跨企业并行生效但受共享Worker/DB资源限制，未达200 |
+
+双企业200档1999条均为单价325：1988条charged金额646100、11条refunded金额3575；2145个包含主备补发的Submit/Outbox全部唯一且published，Outbox最大发布时延0.111秒。1936条delivered、49条模拟器no-receipt保持submitted、11条最终失败已退款、3条首次接受后补发结果码8仍保留charged事实。压测客户端断开后形成的973条pending回执通过14账号零发送排空，最终该档1950条终态回执投递对应1950次ACK，重复0、最大尝试1。
+
+容量结论需限定为10秒短窗口：单企业完整首提由原约96.35提高到122.87 TPS，约提升27.5%；双企业平台总量短窗上限约129.39 TPS，并未线性翻倍。未执行30分钟以上稳态，因此生产建议仍留余量：单企业限速90 TPS、当前单Gateway平台总限速100 TPS；入口可承受150/200冲击不能宣称完整链达到150/200。