docs: clarify TPS contention analysis

2026-07-24 08:27:28 +08:00
parent 39d2cc5909
commit 4f4fa5fcb7
1 changed files with 1 additions and 1 deletions
@@ -2315,5 +2315,5 @@ git diff --check
 - Gateway、API、Nginx、PostgreSQL、Redis 和 MinIO 运行正常，`12026/17890/8090/3000/6379/5432/9000` 监听；本机 API/Gateway health、Redis PONG、公网页面、运营登录入口、客户端登录入口及 API health 均为 HTTP 200，公网 CMPP 17890 TCP 可连接。应用内浏览器连续两次在登录页加载阶段控制超时，因此不虚报 DOM、控制台或登录后页面验收。
 - 5 条 active 供应商通道均恢复为 `connected/currentConnections=1/desiredConnections=1`，主动心跳持续刷新且无 `lastError/lastErrorCategory`；禁用通道为 disconnected。发布后 API/Gateway 的 panic、fatal、unhandled、exception、error 匹配均为 0；`gateway.submit.commands` 保持 `pending=0、lag=0`，压测专用 BullMQ 键清理后为 0。
 - 预发布在真实 API/Gateway 保持运行的条件下，使用不触碰业务 Stream、不访问供应商且最终清理的专用 BullMQ 队列连续执行 3 轮 15000 条测试：完整提交结果与回执闭环分别为 3570.33、3650.92、3587.31 TPS，平均 3602.85 TPS；入队平均 18781.28 TPS。该指标只表示 Redis/BullMQ 与 Node Worker 的内部队列能力，不包含 Prisma 业务事务、计费、路由或真实 CMPP 网络。
- 既往 284.16、376.52、438.93 TPS 的下降主要是测试环境争用而非已证实的代码回归：本机 3000 端口有另一会话从 2026-07-23 23:02 起运行的 API，压测与其共用 Redis、CPU 和事件循环；此前停止 API 后曾恢复至约 872—910 TPS。本轮未终止其他会话进程，改用独立 Redis 后完整 Phase 8 为 549.52 TPS并通过。预发布同一代码三轮约 3603 TPS且方差很小，进一步说明旧低值不能作为平台容量结论。
+- 既往 284.16、376.52、438.93 TPS 的下降主要是测试环境争用而非已证实的代码回归：本机 3000 端口有另一会话从 2026-07-23 23:02 起运行的 API，压测与其争用 Redis 和 CPU；此前停止 API 后曾恢复至约 872—910 TPS。本轮未终止其他会话进程，改用独立 Redis 后完整 Phase 8 为 549.52 TPS并通过。预发布同一代码三轮约 3603 TPS且方差很小，进一步说明旧低值不能作为平台容量结论。
 - 当前真实发送配置的上限不是 3603 TPS：5 条 active 通道各配置 100 TPS，Gateway 总配置上限为 500 TPS；每条通道 1 个连接、窗口 16，API Send Worker 并发 50。真实持续吞吐还受供应商授权 TPS、网络往返、回执速度、数据库和计费事务影响，因此当前预发布应按“内部队列约 3600 TPS、配置发送上限 500 TPS、真实供应商持续能力仍需协议测试环境或供应商配合压测”理解。本次未发送真实短信、未修改生产业务数据。