hectorzhao/lislgosms
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(cmpp): record phase one capacity ceiling

Browse Source
This commit is contained in:
hectorzhao
2026-08-20 18:39:29 +08:00
parent 229a0b28fd
commit 633e7a7055
2 changed files with 6 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/system-functional-test-cases.md
+2
View File
@@ -4743,3 +4743,5 @@ npm run verify:phase8
| TC-CMPP-500-P1-010 | 阶梯压测与对账 | 隔离供应商环境按既定同口径阶梯执行，压后等待全链排空 | 逐档报告SubmitResp、Inbox、两条Stream、最终数据库计数和排空时间；任何丢响应、重复、错误或未排空均失败，不发送真实短信 | | TC-CMPP-500-P1-010 | 阶梯压测与对账 | 隔离供应商环境按既定同口径阶梯执行，压后等待全链排空 | 逐档报告SubmitResp、Inbox、两条Stream、最终数据库计数和排空时间；任何丢响应、重复、错误或未排空均失败，不发送真实短信 |
| TC-CMPP-500-P1-011 | Gateway API连接复用与流量隔离 | 将入站全局窗口设为48，后台协议日志持续写入，并构造Submit专用HTTP客户端 | Submit池每主机最大连接与空闲连接均为48、后台池独立16连接，HTTP总超时仍为10秒；后台日志/回执不得占用Submit连接或造成10秒API超时 | | TC-CMPP-500-P1-011 | Gateway API连接复用与流量隔离 | 将入站全局窗口设为48，后台协议日志持续写入，并构造Submit专用HTTP客户端 | Submit池每主机最大连接与空闲连接均为48、后台池独立16连接，HTTP总超时仍为10秒；后台日志/回执不得占用Submit连接或造成10秒API超时 |
| TC-CMPP-500-P1-012 | API/Worker数据库池隔离 | API与Worker分别配置32/8连接并在Worker积压时持续提交 | 两进程使用各自有界连接池，API受理连接不被Worker抢占；总连接数不超过PostgreSQL上限且压后无`idle in transaction`泄漏 | | TC-CMPP-500-P1-012 | API/Worker数据库池隔离 | API与Worker分别配置32/8连接并在Worker积压时持续提交 | 两进程使用各自有界连接池，API受理连接不被Worker抢占；总连接数不超过PostgreSQL上限且压后无`idle in transaction`泄漏 |
执行记录（2026-08-20，测试环境）：P1-001至009已由API/Gateway自动化、真实PostgreSQL迁移和独立Worker恢复验证覆盖；P1-011专用Submit传输隔离后100、200条/秒分别2999/2999、3998/3998成功，零拒绝、零节流、零连接错误。P1-010在500条/秒档失败：测试环境池调优后10秒仅2979条，实际297.9条/秒且节流611次；全部2979条最终完成并排空，但完整链仅约24条/秒。故第一阶段不通过500条/秒总目标，不执行“完整500条/秒已达标”的结论。
docs/testing-progress.md
+4
View File
@@ -3801,3 +3801,7 @@ git diff --check
- 容量补丁`6708f1f7c540401d1c92083407c3750693bcbb4b`发布前恢复资产位于`/opt/cmpp-platform-backups/p1pool-20260820T101000-before-capacity-isolation`，PostgreSQL 55MB、运行源码187MB、环境/systemd和发布包均经`pg_restore --list`、tar读取及SHA-256校验。测试环境配置API/Worker池32/8，部署后服务、9464/9465回环指标和数据库连接正常。 - 容量补丁`6708f1f7c540401d1c92083407c3750693bcbb4b`发布前恢复资产位于`/opt/cmpp-platform-backups/p1pool-20260820T101000-before-capacity-isolation`，PostgreSQL 55MB、运行源码187MB、环境/systemd和发布包均经`pg_restore --list`、tar读取及SHA-256校验。测试环境配置API/Worker池32/8，部署后服务、9464/9465回环指标和数据库连接正常。
- 补丁后50条/秒30秒生成1499帧，1499/1499成功、零拒绝、零连接错误，P50/P95/P99=`1391/3460/4205ms`，1499条Inbox全部completed，双Stream在注入结束约62秒后归零，入口停止线通过。100条/秒档只生成2719帧（实际90.6条/秒），虽2719/2719成功且P95=4277ms，但客户端窗口被压满1346次，未达到100条/秒目标并停止升档；此时API受理2719个请求全部小于250ms，而Gateway API往返平均3.305秒。 - 补丁后50条/秒30秒生成1499帧，1499/1499成功、零拒绝、零连接错误，P50/P95/P99=`1391/3460/4205ms`，1499条Inbox全部completed，双Stream在注入结束约62秒后归零，入口停止线通过。100条/秒档只生成2719帧（实际90.6条/秒），虽2719/2719成功且P95=4277ms，但客户端窗口被压满1346次，未达到100条/秒目标并停止升档；此时API受理2719个请求全部小于250ms，而Gateway API往返平均3.305秒。
- 100档同时存在大量供应商Submit、回执和通讯日志；`inbound.Server`此前让Submit、协议日志、回执恢复和连接事件共享同一64连接Transport，后台流量仍能占满Submit传输槽。第二个最小补丁将Submit池按入站窗口独立，后台池固定16连接；保留10秒超时和全部日志/回执功能，不靠删除遥测通过压测。该补丁待专项验证、提交和再次建立恢复资产后发布复测。 - 100档同时存在大量供应商Submit、回执和通讯日志；`inbound.Server`此前让Submit、协议日志、回执恢复和连接事件共享同一64连接Transport，后台流量仍能占满Submit传输槽。第二个最小补丁将Submit池按入站窗口独立，后台池固定16连接；保留10秒超时和全部日志/回执功能，不靠删除遥测通过压测。该补丁待专项验证、提交和再次建立恢复资产后发布复测。
- 第二个容量补丁`229a0b28fd8b84d910c359ff9ac442fc3e843cb4`经Gateway全量测试/vet、R6 104声明契约和部署门禁通过。发布前恢复资产`/opt/cmpp-platform-backups/p1submitpool-20260820T102400-before-dedicated-submit`包含PostgreSQL、运行源码、环境/systemd和发布包，均经列表、tar和SHA-256校验；测试环境标记为`229a0b28...+workspace.p1submitpool.f50505ad9ee9`，服务与启动日志正常，预生产未修改。
- 专用Submit池后100条/秒30秒发满2999条，2999/2999成功、零拒绝/节流/连接错误，P50/P95/P99=`42/147/173ms`，API平均约37ms、Gateway API往返平均约54ms；2999条Inbox全部completed，完整供应商链从开始到双Stream排空约132秒，折算约22.7条/秒。200条/秒20秒发满3998条，3998/3998成功、零拒绝/节流/连接错误，分位=`134/370/837ms`；Inbox在开始后约75秒全部完成，双Stream在开始后约166秒排空，完整链折算约24.1条/秒。
- 默认API池32、Submit池64下首次500条/秒10秒只生成1716条，1716/1716成功但节流615次，P95=5217ms，实际171.6条/秒，失败停止。基于PostgreSQL`max_connections=100`和进程连接证据，仅在测试环境把`API_DB_POOL_MAX`调为48、`GATEWAY_CMPP_INBOUND_MAX_CONCURRENCY`调为128，Worker仍为8；复测生成2979条，2979/2979成功、零拒绝/连接错误，P50/P95/P99=`942/1162/3221ms`，但仍节流611次，实际297.9条/秒，500入口仍失败。10个测试连接各窗口32形成320总在途，Gateway平均往返约965ms，实测上限与窗口理论值一致；API平均约322ms，继续只加连接会放大PostgreSQL竞争。
- 最终数据库按四个新号码前缀对账：`1390005/6/7/8`的Inbox completed分别为`2999/3998/1716/2979`，对应`SmsMessageRecord`及唯一MessageId数量完全相同，非completed Inbox为0，命令Stream和结果Outbox均`pending=0/lag=0`，相关服务日志无panic/fatal/Prisma错误或Inbox retry。第一阶段结论为200条/秒入口可靠受理通过、500条/秒入口未通过、完整异步链约24条/秒；不得宣称已完整处理500条/秒。下一阶段必须合并每Submit应用查询与Inbox写入、提高测试连接/窗口总量，并把Worker业务事务、供应商六通道总TPS及结果/回执写入水平扩容，不能再靠单机连接池参数解决。