并发与容量验证
以负载和正确性确定容量范围
指标分开测量
| 指标 | 主要压力 |
|---|---|
| 每秒新调用 | 鉴权、预扣、数据库和任务受理 |
| 同时文本流 | 连接、内存、网络、背压 |
| 在途媒体任务 | 查询／回调、状态更新、Worker 领取 |
| 单账户集中调用 | 额度热点与锁／缓存竞争 |
| 历史数据规模 | 日志、任务、额度记录查询 |
不能只报“支持多少并发用户”。报告必须包含硬件、部署实例、连接池、数据库／Redis 模式、请求分布、持续时长和数据规模。
首批目标：2000 并发
2026-09-21 用户确认预计 2000 并发，并表示服务器配置充足。随后确认流量以持续文本流式连接为主，夹杂普通请求；目标为两者合计2000个同时在途请求/连接，不等于每秒2000次请求。具体流式占比、连接时长分布、目标到达率、P95/P99 和错误预算尚待明确。硬件与部署配置需要实际记录，不凭配置描述判定达标。
用户已指定 oceanway 作为测试服务器。只读盘点为16核、约32GB，现有VOZEB业务继续运行；先使用独立限额、loopback端口和合成网关完成部署形态联调。持续容量阶段仍需将负载发生器与被测服务分开，并确认共享主机资源余量。
首批验收覆盖正式 Edge → Core → 独立文本网关的现行 response-usage 计费链路。当前 capture 本机 1/8/32/64 仅为测试编排与账务基线，不能线性外推至 2000。
| 阶段 | 具体工作与通过条件 |
|---|---|
| 固定环境 | 记录 Edge/Core/Worker 实例、CPU/内存/网卡、代理连接/文件句柄、PG 总连接预算、共享限流、uumi 及供应商额度；压测机与被测服务分开 |
| 生产形态入口 | 业务路由、真实依赖就绪、TLS/代理、超时/关闭/取消和共享限流先验收；禁止把固定503改成200冒充完成 |
| 合成上游隔离 | 使用现行 response-usage 与冻结模型价格/上界/证据机制，分别测四协议普通/SSE；合成上游明确标识，先定位平台瓶颈，不产生真实供应费用 |
| 逐级增加 | 64→128→256→512→1000→1500→2000；每档记录实际在途高水位、到达率、完成率、首字节与总时延、锁/连接等待和资源，失败不直接跳到更高档 |
| 持续与流量分布 | 首轮建议每档稳定观察5分钟，目标档至少30分钟，再安排长稳；这些是测试设计值，业务SLO另确认。先分别测普通请求与持续流式，再测以流式为主的混合负载；多客户分散与单钱包热点分开判定，包含流结束集中结算 |
| 故障下账务 | 在可控档位注入断连、慢读、Core/Edge/Worker重启和依赖故障；新请求限流可预测，缺证据保留预占，恢复不重发模型、不重复扣款，最终逐客户逐操作对账 |
| 上游联合验收 | 另在明确调用模型、费用和供应限额的范围内验证真实uumi路径；平台合成负载通过不表示供应商支持2000并发，也不授权2000路付费压测 |
持续阶段工具与执行记录见NEXT-11 持续流式验证。本机独立Go发生器经SSH隧道连接隔离服务，按实测活跃流及采样覆盖决定扩量，每档先完成Core API逐笔对账。低带宽心跳SSE不能当作真实token吞吐。
本机同步线程式短突发工具不直接扩为2000线程正式压测器。后续选用异步或分布式负载驱动，验证驱动器自身CPU、连接与事件循环未成为瓶颈；流式连接驻留期间不应长期占用数据库事务/连接。数据库池不按流数设置为2000，按实例总量、事务时长和实际等待调优。
停止扩量条件包括账务/权限错误、资源或队列持续增长、恢复积压不可收敛；性能阈值待SLO确认。任何档位出现上述问题先定位，测试报告保留失败档和未测范围。
场景
多账户均匀流量与单热点账户；额度临界点；流式客户端断开；媒体长时间不返回；重复回调；进程退出；Redis 故障／缓存重建；数据库延迟和积压恢复。账务正确性与吞吐同时检查，不以放宽扣费保证换取好看的数字。
判定
记录吞吐、P95／P99、错误比例、连接与内存、队列积压及账务核对。达到具体目标前不承诺容量；限流和拒绝行为可预测，超载时不能无限堆积。优化以实测瓶颈为依据，模块和进程拆分可晚于第一轮测量。