容量与性能优化
优化应从指标和瓶颈开始。Sub2API 的慢可能在上游、并发排队、Redis、PostgreSQL、反向代理、协议转换或日志写入，不能只看应用 CPU。
建立基线
记录峰值和典型值：QPS、TPS、TTFT P50/P95/P99、总耗时、错误率、上游错误率、队列深度、账号切换率、DB 连接等待、Redis 延迟、CPU/内存和 usage 写入延迟。
优化前后使用相同平台、Group、模型、流式模式和流量分布比较。
症状到瓶颈
| 症状 | 可能瓶颈 | 首要动作 |
|---|---|---|
| TTFT 高、应用资源低 | 上游/Proxy/模型排队 | 按 account/供应商切分 |
| queue 增长、账号满 | 账号池容量 | 增加独立额度或调整流量 |
| DB waiting 增长 | 连接池/慢查询 | 查连接、查询和实例总池大小 |
| Redis 延迟高 | 热 key/连接/内存 | 查 latency、eviction、pool |
| CPU 高 | 转换、JSON、日志、压测过量 | profile 并按 endpoint 分解 |
| 内存持续增长 | 长流、缓冲、队列 | 看活跃请求、响应大小、goroutine |
| 日志 dropped | 日志写入压力 | 采样、保留、数据库写入 |
账号池优化
- 不以提高单账号并发对抗上游 429。
- 用多个独立上游项目/供应商分散故障域。
- 高延迟账号降低优先级，而不是反复清限流。
- 灰度验证新的 load factor 和优先级。
- 监控切换率；频繁切换通常意味着池不稳定。
PostgreSQL 与 Redis
所有应用副本连接池总和必须小于数据库 max_connections 并保留运维余量。Redis 需要关注连接数、内存、evicted keys、blocked clients 和延迟；它承载调度运行时状态、并发、缓存、粘性和分布式锁，退化会表现为多种业务症状。
基础设施参数见PostgreSQL 与 Redis和多实例。
日志和聚合成本
- 高流量环境启用合理采样，不记录敏感 body。
- 设置 Ops/usage 保留期和预聚合。
- 长时间窗口优先使用 preaggregated 数据。
- 监控 cleanup/aggregation heartbeat。
- 不在高峰执行大范围 raw 报表或无索引查询。
优化验收
优化必须同时满足：目标指标改善、错误率不升、费用不漂移、模型映射不变、故障切换仍工作、重启/多实例行为一致。单次压测更快但生产错误率变高不算成功。