docs: diagnose paid single-tenant throughput ceiling

2026-08-25 16:38:59 +08:00
parent 9292352be1
commit d3ceeb1e16
2 changed files with 27 additions and 0 deletions
@@ -3965,3 +3965,14 @@ git diff --check
 - 正价325阶梯入口SubmitResp：20=199/199、P95/P99 10/16ms；30=299/299、10/18ms；50=499/499、35/47ms；70=699/699、44/60ms；100=999/999、51/72ms；150=1498/1498、87/114ms；200=1998/1998、84/110ms；全部零拒绝、零节流、零连接错误。完整供应商首提速率依次为19.84/30.34/49.47/65.54/74.86/94.86/92.24 TPS，端到端天花板约95 TPS。
 - 最终100 TPS正价复验：999/999，P50/P95/P99 54/102/179ms；999个唯一MessageId，1087个含主备补发的submitId全部唯一；999次999个唯一首提在12.488秒完成（80.00 TPS）。972条终态回执全部客户ACK，下游尝试972、重复0、最大1。计费998条中995 charged、3 refunded；1条RISK供应商前失败不计费；27条no-receipt保持submitted。Inbox/Outbox/下游pending队列、未授权锁和idle transaction最终均0。
 - 最终建议分口径：客户入口可受理200 TPS冲击，不等于端到端供应商200 TPS；供应商首提峰值约95 TPS，建议稳定限速70 TPS保留余量。按用户要求，7个应用单价保持325，三条临时号段规则、Tailscale白名单及VM回环白名单均保留，未做删除或归零。压测原始证据已复制到相邻测试项目lg-cmpp-stress-lab/results下的phase5-replayfix目录。
+
+## 2026-08-25 95 TPS天花板定向诊断
+
+- 先将第五阶段容量扩展和回执防重修复提交为`9292352`，排除`*.tsbuildinfo`、`outputs/`、`pnpm-lock.yaml`、空文件`=`及无关临时脚本；未push。随后仅在`100.93.204.60`测试环境和本地隔离供应商模拟器执行正价诊断，预生产未操作。
+- 100 TPS档998/998受理，P50/P95/P99=`57/117/257ms`，首次供应商Submit跨度13.172秒、约75.76 TPS；150 TPS档1498/1498受理，P50/P95/P99=`71/136/185ms`，首次供应商Submit跨度15.547秒、约96.35 TPS。两档均零拒绝、零节流、零连接错误，单价均325。
+- Gateway不是当前天花板：6/6供应商连接、总窗口192；150档连接等待均值0.006ms、供应商RTT均值13.761ms、窗口采样峰值10、命令Stream lag峰值27。150档供应商模拟器新增1603次尝试、1574次接受、29次拒绝、错误0；105次主备补发解释了尝试数高于业务消息数。
+- 天花板位于独立CMPP入站工作流。7个压测应用全部属于同一企业`qa-bell-alerts-tenant`，因此日限、号码频控、消息持久化和正价账户冻结集中在同一企业边界。100档Inbox 998条形成171个完成批次，平均5.84条、最大16条，注入9.991秒但排空13.245秒，完成延迟P50/P95=`3053/3810ms`；150档1498条形成153个完成批次，平均9.79条、最大22条，注入9.974秒但排空15.555秒，完成延迟P50/P95=`3779/5620ms`。配置虽为工作流并发96、批次64，但泵在每批完成后立即领取当时已有记录，没有有界聚合等待，稳态产生大量小批次。
+- 150档阶段指标均值显示`risk_frequency≈202.05ms`、`message_persist≈183.57ms`、`daily_quota≈152.86ms`；`pg_advisory_xact_lock`164次累计6.897秒、均值42.057ms。BullMQ waiting峰值0、发送Worker槽峰值76/96、数据库池waiting峰值0；Gateway命令和结果Stream、Inbox及Submit Outbox最终全部排空，数据库无等待锁和idle transaction。主机CPU一分钟窗口峰值约65.47%、内存约40.74%，不是CPU或内存打满。
+- 结论应限定为“单企业正价完整首提约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。