From d3ceeb1e16e3437851603bf36a43978f41a70436 Mon Sep 17 00:00:00 2001 From: hectorzhao Date: Tue, 25 Aug 2026 16:38:59 +0800 Subject: [PATCH] docs: diagnose paid single-tenant throughput ceiling --- docs/phase-5-gateway-capacity-expansion-plan.md | 16 ++++++++++++++++ docs/testing-progress.md | 11 +++++++++++ 2 files changed, 27 insertions(+) diff --git a/docs/phase-5-gateway-capacity-expansion-plan.md b/docs/phase-5-gateway-capacity-expansion-plan.md index 7efbacd..726953b 100644 --- a/docs/phase-5-gateway-capacity-expansion-plan.md +++ b/docs/phase-5-gateway-capacity-expansion-plan.md @@ -491,3 +491,19 @@ API 必须返回逐事件结果，而不是只有整批成功或失败： 直推领取修复后另执行100 TPS正价复验：999/999，P50/P95/P99=54/102/179ms；999个唯一MessageId、999次非补发首提在12.488秒完成（80.00 TPS）。972条已产生最终回执的投递全部ACK，生命周期尝试972、重复0、最大尝试1。计费998条：995 charged、3条供应商最终失败后refunded；1条RISK在供应商前失败且未计费。27条模拟器no-receipt保持submitted，不是队列丢失。Inbox、Submit Outbox、下游pending/dispatching/awaiting_ack、未授权锁和idle transaction最终均为0。 最终结论分两种口径：客户入口SubmitResp受理已通过200 TPS冲击；完整供应商首提天花板约95 TPS。测试环境建议稳定限速70 TPS，保留约25%以上端到端余量；不将入口200 TPS宣称为供应商200 TPS。按用户要求，7个测试应用单价保持325，^1380028/^1300028/^1890028三条临时号段规则保留，原100.91.249.119/32和新增127.0.0.1/32白名单均保留，未做测试后删除或归零。 + +## 14. 95 TPS天花板定向诊断 + +100/150 TPS正价复验确认，Gateway的6条连接和192个窗口没有饱和；150档连接等待仅0.006ms、供应商RTT约13.761ms、窗口峰值10，命令Stream lag峰值27。真正的平台内排队发生在耐久Inbox之后、BullMQ发送之前的独立CMPP入站工作流。 + +当前7个压测应用全部归属同一企业。尽管工作流配置为并发96、批次64，泵在一批完成后立即领取当时已有记录，100/150档实际平均批次仅5.84/9.79条，导致同一企业的日限、号码频控、消息持久化和正价账户冻结被大量小事务重复执行。150档Inbox完成延迟P50/P95为3.779/5.620秒，1498条首次供应商Submit用15.547秒完成，即约96.35 TPS；因此当前约95 TPS应定义为“单企业正价完整首提上限”，不能定义为多企业平台总上限。 + +下一阶段优先级： + +1. 为入站工作流增加按企业分组的有界微批，目标批次32～64、最大等待20～50ms； +2. 不同企业允许并行，同企业账户冻结保持串行和幂等； +3. 继续合并配额、频控、消息及冻结流水的集合事务； +4. 分别验证单企业100/150 TPS，以及至少两个独立企业合计200 TPS； +5. 只有单Gateway资源被实测打满后才启动多Gateway P2。 + +诊断还发现Outbox原生SQL使用`CURRENT_TIMESTAMP`，与Prisma UTC时间混用时会产生8小时审计偏差。该问题不影响本次吞吐和队列排空结论，但必须在下一次代码改造中统一为UTC并回归租约、重试和发布时延。 diff --git a/docs/testing-progress.md b/docs/testing-progress.md index 698d449..18459a0 100644 --- a/docs/testing-progress.md +++ b/docs/testing-progress.md @@ -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。