性能与故障转移调优
高吞吐场景下的上游调优——超时与重试、健康检查与熔断、加权恢复,以及并发处理度、请求队列容量与队列溢出策略的配置口径与取值指引
本页讲清在高吞吐场景下如何调优上游接入的性能与韧性。调优分两类:一是韧性侧——超时、重试、健康检查、加权恢复,决定单个上游不稳定时请求如何容错;二是吞吐侧——并发处理度、请求队列容量、队列溢出策略,决定平台在高流量下如何排队与背压。两类参数均按上游分别配置,可在「模型接入」页或控制平面 /api/v1/providers 上调整。
1. 韧性参数:超时、重试、健康检查
每个上游接入维护一组韧性参数,控制请求在该上游上的容错行为:
| 参数 | 含义 | 默认取向 |
|---|---|---|
request_timeout | 单次上游调用的超时时长,超时即判定本次失败 | 按上游典型时延留足余量 |
max_retries | 同一上游内的最大重试次数,重试用退避间隔 | 谨慎取值,避免放大上游压力 |
retry_backoff_initial | 首次重试的退避起点 | 较短,快速试探 |
retry_backoff_max | 退避上限,多次重试不超过此间隔 | 防止重试间隔无限拉长 |
health_check | 选用前的健康检查开关,不健康即熔断降级 | 默认开启 |
curl https://your-platform/api/v1/providers/<上游标识> \
-X PUT \
-H "Content-Type: application/json" \
-H "Cookie: <控制台会话凭证>" \
-d '{
"request_timeout": "60s",
"max_retries": 1,
"retry_backoff_initial": "100ms",
"retry_backoff_max": "2s",
"health_check": true
}'一次请求在韧性参数下的容错路径:
- 超时:上游调用超过
request_timeout即判失败,进入重试或降级。 - 重试:在同一上游内按退避间隔重试,至多
max_retries次;退避从retry_backoff_initial起、不超过retry_backoff_max。 - 健康检查与熔断:选用候选前做健康检查;不健康的上游被短路熔断,按优先级或路由规则的
fallbacks降级到下一候选(见通用接入规则 §5)。
2. 加权恢复
被熔断或降权的上游恢复后,平台采用加权恢复而非一次性满负荷切回——避免刚恢复的上游被瞬时流量再次压垮:
| 机制 | 行为 |
|---|---|
| 渐进升权 | 上游恢复健康后,其承接权重从低位逐步回升,平滑切回流量 |
| 探测放量 | 恢复期保留一小比例探测流量试探上游,确认稳定后再放大权重 |
| 状态流转 | 上游在「健康 → 降级 → 熔断 → 恢复中」间流转,恢复中的上游以受限权重参与路由 |
加权恢复使路由在上游抖动后能快速降权、又能在其恢复后稳健回切,整个过程的状态流转与权重变化可在「请求监控」页查看。
3. 吞吐参数:并发处理度与请求队列容量
每个上游接入配两个吞吐参数,按该上游的预期请求速率设定:
| 参数 | 作用域 | 说明 |
|---|---|---|
并发处理度(concurrency) | 按上游 | 同时处理该上游请求的并发处理槽数;越高吞吐越大、资源占用越多 |
请求队列容量(buffer_size) | 按上游 | 请求被处理前可排队的最大条数;越大越能吸收流量突刺 |
curl https://your-platform/api/v1/providers/<上游标识> \
-X PUT \
-H "Content-Type: application/json" \
-H "Cookie: <控制台会话凭证>" \
-d '{
"concurrency": 200,
"buffer_size": 1000
}'约束:队列容量 ≥ 并发处理度。 若
concurrency > buffer_size,上游接入配置会被拒绝。建议把队列容量设为并发处理度的约 1.5 倍,既能吸收突刺、又能在内存耗尽前及时背压。
3.1 取值指引
按该上游的预期请求速率设定,常用对照(速率单位:请求/秒):
| 预期速率 | 并发处理度 | 请求队列容量 |
|---|---|---|
| 100 | 100 | 150 |
| 500 | 500 | 750 |
| 1000 | 1000 | 1500 |
| 2500 | 2500 | 3750 |
| 5000 | 5000 | 7500 |
经验公式:
并发处理度 = 预期请求速率
请求队列容量 = 1.5 × 预期请求速率各上游按各自的速率限制与时延特性独立调优——速率宽松、吞吐高的上游可取较大并发处理度;速率紧、时延高的上游应取较保守的值,否则只会触发上游限速。不要把并发处理度设得超过上游速率上限。
4. 队列溢出策略
当某上游的请求队列达到容量上限时,行为由 drop_excess_requests 控制:
| 策略 | 取值 | 行为 | 适用 |
|---|---|---|---|
| 阻塞模式(默认) | false | 新请求等待直到队列腾出空间;不丢请求,但高负载下时延上升 | 每条请求都不能丢的关键工作负载 |
| 丢弃模式 | true | 队列满时新请求立即拒绝并返回错误;保证已受理请求的时延稳定 | 陈旧请求无价值的实时场景 |
curl https://your-platform/api/v1/providers/<上游标识> \
-X PUT \
-H "Content-Type: application/json" \
-H "Cookie: <控制台会话凭证>" \
-d '{ "drop_excess_requests": true }'生产建议。 多数生产工作负载推荐"丢弃模式 + 队列容量取并发处理度 1.5 倍":既能吸收合理的流量突刺,又能在极端过载时以背压保护内存,而非无限排队拖垮整体时延。
5. 监控与诊断
调优后须持续观测,按实际流量回调参数。关键指标与处置:
| 指标 | 健康区间 | 越界处置 |
|---|---|---|
| 队列深度 | < 队列容量的 50% | 增大队列容量或并发处理度 |
| 请求时延(p99) | < 平均值的 2 倍 | 检查上游速率限制 |
| 被丢弃请求数 | 0 | 增大队列容量 |
| 重试与降级率 | 稳定低位 | 检查上游健康与超时设置 |
上述指标可在「请求监控」页(GET /api/v1/monitor/overview)查看;逐上游的探测耗时、队列深度与状态流转在「模型接入」页与监控视图中同源呈现,跨页面核对时数字一致。
6. 调优速查
韧性侧:
request_timeout 按上游典型时延留余量
max_retries 谨慎,避免放大上游压力
health_check 默认开启,不健康即熔断降级
加权恢复 渐进升权 + 探测放量,避免恢复瞬间再次压垮
吞吐侧:
并发处理度 = 预期请求速率
请求队列容量 = 1.5 × 预期请求速率(且 ≥ 并发处理度)
队列溢出 生产推荐丢弃模式 + 1.5 倍队列容量
通用:
起步从保守值开始,按观测到的队列深度/时延/丢弃率逐步上调
各上游独立调优,并发处理度不超过上游速率上限