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。
@@ -154,7 +154,7 @@ curl http://127.0.0.1:12026/
 redis-cli -h 127.0.0.1 -p 6379 ping
 pg_isready -d "$(grep '^DATABASE_URL=' /etc/cmpp-platform/cmpp-platform.env | cut -d= -f2-)"
 grep -E '^(API_ENABLE_SEND_WORKER|API_SEND_WORKER_CONCURRENCY|GATEWAY_SUBMIT_WORKER_CONCURRENCY|GATEWAY_SUBMIT_RESULT_WORKER_CONCURRENCY|GATEWAY_CMPP_INBOUND_MAX_CONCURRENCY)=' /etc/cmpp-platform/cmpp-platform.env
-grep -E '^(CMPP_INBOUND_FAST_PATH_ENABLED|CMPP_INBOUND_WORKFLOW_WORKER_ENABLED|API_INBOUND_WORKFLOW_CONCURRENCY|API_INBOUND_WORKFLOW_BATCH_ENABLED|API_INBOUND_WORKFLOW_BATCH_SIZE|API_INBOUND_WORKFLOW_POLL_INTERVAL_MS|API_INBOUND_WORKFLOW_STALE_SECONDS|API_DB_POOL_MAX|API_WORKER_DB_POOL_MAX|API_WORKER_METRICS_PORT)=' /etc/cmpp-platform/cmpp-platform.env
+grep -E '^(API_HTTP_KEEP_ALIVE_TIMEOUT_MS|API_HTTP_HEADERS_TIMEOUT_MS|CMPP_INBOUND_FAST_PATH_ENABLED|CMPP_INBOUND_WORKFLOW_WORKER_ENABLED|API_INBOUND_WORKFLOW_CONCURRENCY|API_INBOUND_WORKFLOW_BATCH_ENABLED|API_INBOUND_WORKFLOW_BATCH_SIZE|API_INBOUND_WORKFLOW_BATCH_WAIT_MS|API_INBOUND_WORKFLOW_TARGET_BATCH_SIZE|API_INBOUND_WORKFLOW_POLL_INTERVAL_MS|API_INBOUND_WORKFLOW_STALE_SECONDS|API_DB_POOL_MAX|API_WORKER_DB_POOL_MAX|API_WORKER_METRICS_PORT)=' /etc/cmpp-platform/cmpp-platform.env
 systemctl is-active cmpp-api cmpp-send-worker cmpp-gateway
 curl -fsS http://127.0.0.1:9465/metrics | grep '^cmpp_worker_inbound_workflow_'
 redis-cli --scan --pattern 'rate:gateway:channel:*'
@@ -187,3 +187,4 @@ bash tools/deploy/production-deploy.sh
 - Worker日志目录归`cmpp-api:cmpp-security`且仅服务可写，9465只监听回环并加入Prometheus `cmpp-send-worker` target。发布后必须验证两进程均为非root、API/Gateway health、Worker metrics、PostgreSQL/Redis，以及Inbox pending/processing/最老等待可观测。
 - 回滚前先停止Gateway、API和Worker，保留故障现场Inbox及日志；如恢复旧数据库备份，必须同时恢复对应源码和环境/systemd资产。不得在回滚时删除pending Inbox或重投真实短信。
 - 第三阶段要求环境显式设置`API_INBOUND_WORKFLOW_BATCH_ENABLED=true`和正整数`API_INBOUND_WORKFLOW_BATCH_SIZE`，初始建议64且不得大于Worker业务槽的可解释倍数。批次增大前必须核对PostgreSQL参数数量、单事务持续时间、Worker RSS和租约时长；付费短信仍走逐条账务锁，不能用零计费批量结果替代付费链路验收。
+- 单企业微批阶段要求显式设置`API_INBOUND_WORKFLOW_BATCH_WAIT_MS=40`、`API_INBOUND_WORKFLOW_TARGET_BATCH_SIZE=32`，目标不得超过批次上限；发布脚本拒绝负等待、超过250ms或目标越界。API还必须设置`API_HTTP_KEEP_ALIVE_TIMEOUT_MS=120000`和更大的`API_HTTP_HEADERS_TIMEOUT_MS=125000`，确保服务端keep-alive长于Gateway 90秒空闲池；发布后用响应头回读实际timeout并检查Gateway日志无loopback reset。
@@ -4887,3 +4887,5 @@ npm run verify:phase8
 | TC-CMPP-PHASE5-016 | 微批发布边界与停止线 | 仅单Gateway；分别验证单企业100/150与多企业200，发生拒绝、连接错误、持续积压、数据库异常或账务不一致立即停止 |
 | TC-CMPP-PHASE5-017 | Gateway到API长连接生命周期 | API keep-alive 120秒大于Gateway连接池90秒，headers timeout更大；跨越Node原默认5秒空闲边界后继续压测，不得出现loopback connection reset或Result 9 |
 | TC-CMPP-PHASE5-018 | 同连接并发状态回调 | 同一connectionId的connected与submit并发时幂等upsert且保持在线；不同connectionId超过cmppMaxConnections仍403，不能误断当前连接或漏SubmitResp |
+
+执行记录：按企业微批发布后，单企业100 TPS为999/999响应、P95/P99=`243/466ms`、首次供应商Submit=`95.85 TPS`；单企业150 TPS冲击为1498/1498、`83/117ms`、首次Submit=`122.87 TPS`；双企业200 TPS冲击为1999/1999、`148/287ms`、首次Submit=`129.39 TPS`。三档最终有效运行均零拒绝、零节流、零连接错误，价格均325。双企业档账务1988 charged/646100、11 refunded/3575；2145个Submit/Outbox唯一，1950条终态回执投递1950次、重复0，973条离线pending通过零发送客户端排空。多Gateway P2未实施。
@@ -3976,3 +3976,12 @@ git diff --check
 - 结论应限定为“单企业正价完整首提约95 TPS”，不能外推为多企业平台总吞吐。下一步优先为入站工作流增加按企业分组的有界微批（目标批次32～64、最大等待20～50ms）并对不同企业并行、同企业账户冻结串行；同时把配额/频控/消息持久化合并为更少的集合事务。之后用同企业100/150和至少2个独立企业的总200 TPS正价场景分别验收。多Gateway仍不是当前优先项。
 - 诊断另发现`GatewaySubmitOutbox.createdAt`由Prisma按UTC写入，而原生SQL以`CURRENT_TIMESTAMP`写`publishedAt/updatedAt`，测试机数据库会话时区为Asia/Shanghai时产生8小时显示偏差。该问题不影响本次Stream排空和首提TPS，但会污染Outbox发布时延审计，需单独将原生SQL时间统一为`NOW() AT TIME ZONE 'UTC'`并回归租约/重试时间语义。
 - 收尾回读：9个核心服务均active，六连接在线；命令/结果Stream pending和lag均0，协议日志Stream长度0；7个应用继续active、接口开启、单价325，`^1380028/^1300028/^1890028`三条priority10规则继续active，每个应用的`100.91.249.119/32`及`127.0.0.1/32`白名单均保留。发布窗口API/Gateway/Worker/回调error级journal为0。
+
+## 2026-08-25 单企业微批、连接竞态修复与双企业正价容量验证
+
+- 提交`76e7c8c`：入站工作流领取前最多40ms聚合到目标32/上限64，按企业分组，不同企业并行、同企业分批串行并从后续领取排除；Submit Outbox及关联消息原生SQL统一为UTC。API完整45套525项（后续连接修复后526项）、TypeScript构建、Gateway全包测试/go vet、R0、发布契约和真实PostgreSQL SQL门禁通过。
+- 100 TPS首轮998条出现2个Result 9，日志证明为Gateway复用API loopback连接时被Node默认keep-alive关闭；`394949f`设置API keep-alive/headers timeout为120/125秒并由部署脚本校验。复验不再出现loopback reset，但`920004`连接只返回9条后断开；日志定位同一connectionId的connected/submit状态回调竞态被误判超过1条连接。`b5005f2`改为同connectionId不重复计数、首次状态幂等upsert，保留不同连接超限403。
+- 三次发布均只到`100.93.204.60`，预生产和多Gateway P2未操作；最终标记`b5005f21d5092b7e2759efdce0ebd02798e4552f+test.phase6.tenant-microbatch.utc.keepalive.connection-race`。最终恢复点`/opt/cmpp-platform-backups/phase6-connection-race-20260825T095448Z`，另保留实施前和keep-alive修复前两份可读恢复集；每份均含custom dump、运行源码、环境/systemd和SHA-256，pg_restore/tar校验通过。
+- 有效正价结果：单企业100档999/999、P50/P95/P99=`72/243/466ms`、23个批次平均43.43/最大64、Inbox 10.721秒排空、首次供应商Submit `95.85 TPS`；单企业150冲击1498/1498、`53/83/117ms`、33批平均45.39/最大64、12.453秒排空、首次Submit `122.87 TPS`；双企业合计200冲击1999/1999、`80/148/287ms`、两企业各22批、首次Submit `129.39 TPS`，两企业分别64.69/65.96。全部零拒绝、零节流、零连接错误。
+- 双企业200档单价全部325：1999条账务记录，其中1988 charged/646100、11 refunded/3575；2145个含主备补发的SubmitId及Outbox全部唯一/published，Outbox最大发布0.111秒。最终1936 delivered、49模拟器no-receipt为submitted、11最终失败已退款、3条首次接受后补发结果码8保留charged。1950条终态回执投递1950次、重复0、最大尝试1；客户端离线产生的973 pending由14账号零发送排空。
+- 收尾状态：Inbox全83194条completed，Submit Outbox全27107条published，命令/结果/协议日志Stream pending和lag均0，下游pending=0，数据库锁等待/idle transaction=0，9服务active、API/Gateway健康、Redis PONG；14个测试应用active且单价325，28条指定白名单保留，原phase5三条和新增phase6三条临时号段规则均active。未执行长期稳态，当前建议单企业限速90 TPS、单Gateway平台总限速100 TPS；入口150/200冲击不等于完整供应商TPS。