docs: record CMPP phase two pressure results

This commit is contained in:
hectorzhao
2026-08-20 19:13:46 +08:00
parent f4560479d3
commit 57192b7586
2 changed files with 6 additions and 0 deletions
+4
View File
@@ -3813,3 +3813,7 @@ git diff --check
- 普通短短信快路径已改为单个PostgreSQL CTE:使用账号唯一索引读取应用和企业当前状态,在同一快照校验接口、IP白名单及Src_Id,并以请求键`ON CONFLICT DO NOTHING`幂等写Inbox和稳定响应。正常路径不再先执行Prisma应用查询;仅并发唯一键竞争且当前快照看不到胜者时执行一次只读恢复,避免用自更新制造表膨胀。长短信分片状态机保持不变。
- Inbox Worker领取后改为按本批唯一`applicationId`一次查询应用、企业和白名单,再逐条处理;不做跨批应用状态缓存,领取事务仍不包住风控、计费、Redis或供应商调用。专项SendChain 121项、API全量42套493项、API与前端TypeScript、Vite生产构建、Prisma validate、Gateway全量测试/vet、5份Stream契约、R0/R6/R7/R10、安全/部署门禁和`git diff --check`均通过;R9仍只被HEAD既有`dispatchDueScheduledTasks`哈希漂移阻断,未改写该方法。提交、恢复资产、测试环境发布和100→200→500阶梯结果待后续补记。
- 主提交`99fb346c125b0f620641562c50ad517a7682a10f`发布到测试环境后,100条/秒首轮2998个请求全部收到业务拒绝且API返回500,立即按停止线终止升档。日志给出PostgreSQL `42P18 could not determine data type of parameter $11`;参数定位为`jsonb_build_object`的多态value位置没有为MessageId/phoneCount声明类型。该轮没有新增Inbox或业务短信,不计容量结果;修复为显式`text/integer`类型后须重新走门禁、提交和发布验证。
- 类型修复提交为`f4560479d3bcb9f1b1a6fc9b1b2664a997cdf851`,测试环境最终标识为`f4560479...+workspace.p2fix.51553e0d5555`,未推送。首次发布恢复资产`/opt/cmpp-platform-backups/p2-20260820T105600Z`和修复发布恢复资产`/opt/cmpp-platform-backups/p2fix-20260820T110500Z`均包含PostgreSQL custom dump、完整运行源码、环境和systemd,分别通过`pg_restore --list`、tar读取与SHA-256校验。最终修复包大小2431905字节,本地/测试机SHA-256均为`51553e0d5555ee6a6f3317cc1a4b99410d2c0cd717ad37eac0fc839e91baa2fd`92条migration无待执行项,API/Gateway/Worker/PostgreSQL/Redis/Nginx/Prometheus均active。预生产只读标识仍为`433b2ee56f6016ad8afff1bac73f510b8fd53083+gateway-v2.cd7bb8d05e7b`,未发布、未回退、未压测。
- 仅在测试环境连接总预算内设置API/Worker池48/32、Inbox业务槽96、BullMQ发送槽96、Gateway Submit槽128、结果Outbox槽32和客户入站上限128;代码默认值未改变,PostgreSQL`max_connections=100`仍保留至少20条非业务池余量。修复后1条/秒低负载9/9受理、P95=41msInbox与短信主记录均9条且MessageId唯一,双Stream归零。
- 正式100条/秒30秒档生成2998条,2998/2998成功,零拒绝、零节流、零连接错误,P50/P95/P99=`34/79/128ms`;相较第一阶段100条/秒P95=147ms,合并SQL在更高Worker竞争下仍降低入口尾延迟。数据库2998条Inbox全部completed、2998条短信主记录及唯一MessageId完全对账,Inbox从首条创建至末条完成约52.1秒,折算约57.5条/秒。
- 该档未通过“完整处理100条/秒”停止线:全部为移动号码并只走`LGST-M-P`主通道,最终产生3863次供应商尝试,其中accepted3118、rejected78、timeout667;回退通道接受846次。命令Stream和结果Outbox从首条接收至最终0/0约136秒,按2998条业务短信折算约22.0条/秒;最终消息delivered2797、failed70、submitted131。高峰期间API后台协议日志、连接状态和待投递查询出现超时,说明提高Worker/Outbox槽后共享API/数据库回调仍受争用。因100档完整链已经失败,按阶梯停止线没有继续200/500档,不能宣称完整500条/秒达标。