性能与可靠性测试

性能测试不是一次缺少负载模型的压力工具执行。它需要在明确的负载模型、正确性约束和资源预算下，确定吞吐、延迟、容量与故障恢复边界。Agent系统还需要考虑模型队列、Token、Tool Fan-out和成本，单独使用平均耗时容易掩盖长尾问题。

1. 先区分测试类型

类型	目标	负载形状
Microbenchmark	比较局部实现	单函数、稳定输入
Load Test	验证预期负载	目标QPS与用户模型
Stress Test	找极限和退化方式	持续增加直到失败
Spike Test	验证突发流量	短时陡增与回落
Soak Test	找泄漏和累积问题	长时间稳定负载
Scalability Test	验证扩容曲线	增加实例与负载
Chaos / Fault Injection	验证故障处理	延迟、丢包、宕机、限流

2. 核心指标

Throughput：单位时间完成请求数。

X=\frac{N_{\text{completed}}}{T}

Error Rate：

E=\frac{N_{\text{failed}}}{N_{\text{total}}}

Latency应使用分位数而不仅是平均值。P99=2 s表示99%的请求不超过2 s，仍有1%的请求更慢；对于每天一百万次请求，这部分包含一万次请求，不能作为罕见情况忽略。

3. Little’s Law做容量估算

稳定系统中：

L=\lambda W

$L$ ：系统平均在途请求数；
$\lambda$ ：平均到达率；
$W$ ：平均停留时间。

若Agent任务到达率2 req/s，平均运行30 s，则平均60个任务在途。每个任务并行3个Tool Call，下游峰值并发可能远高于60，需要根据阶段分布和Fan-out继续建模。

4. 负载模型必须像真实业务

写清：

到达模型：Constant、Ramp、Poisson、Burst；
请求Mix：读写比例、Tool类型、Query复杂度；
数据分布：热门Key、长尾Tenant、大文档；
Session行为：Think Time、连接复用、SSE存活时间；
冷热状态：缓存、连接池、模型Warmup；
环境：实例、CPU、内存、网络、依赖版本。

如果压测仅包含最短Prompt和缓存命中场景，结果将无法代表真实负载分布下的系统性能。

5. Go Benchmark

func BenchmarkFuseCandidates(b *testing.B) {
    sparse, dense := fixtureCandidates(1000)
    b.ReportAllocs()
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        _ = FuseRRF(sparse, dense, 60)
    }
}

报告ns/op、B/op、allocs/op；固定CPU频率和环境，多次运行并做统计比较。Benchmark只解释局部热点，不等于端到端吞吐。

性能回归门禁应使用相对变化和噪声区间，例如仅在P50回归超过10%且具有统计显著性时阻断。单次云主机基准测试可能存在环境波动，不应直接触发回归结论。

6. Coordinated Omission

闭环压测器等待上一请求完成后才发下一请求，系统变慢时发得更少，恰好漏掉用户本该继续到达的请求，测出的尾延迟过于乐观。开放负载模型按计划到达率发请求，更接近真实排队。

压测报告说明工具是否修正Coordinated Omission、队列等待是否计入Latency、客户端是否自身先耗尽CPU。

7. 饱和、排队与背压

随着负载增加，典型曲线：

低负载：吞吐线性增长，延迟稳定
接近饱和：吞吐增长变慢，P99上升
超过容量：队列堆积、超时、重试、雪崩

测试要验证系统如何拒绝过载请求：返回429/Resource Exhausted、限制排队长度、提供Retry-After、按优先级处理并执行Load Shedding。无限Queue可能暂时降低显式错误率，但会持续放大排队延迟，使响应在到达用户时已经失去时效性。

8. Soak Test找什么

Goroutine、Thread、File Descriptor泄漏；
Heap增长与GC Pause；
连接池失效；
Cache无界增长；
Kafka Lag累积；
Token/Rate Limit窗口错误；
临时文件和Trace Artifact不清理；
模型或GPU长期碎片化。

Soak至少跨过关键生命周期：Token刷新、证书轮换、TTL、日志切割和定时任务。

9. 故障注入

按层注入：

Network：延迟、丢包、Reset、DNS失败
Service：500、429、慢Header、Malformed Body
Storage：锁等待、只读、磁盘满、主从切换
Queue：重复、乱序、Lag、Rebalance
Model：Timeout、Rate Limit、Refusal、Malformed Tool Call
Tool：部分成功、结果过大、审批拒绝

每个实验应定义Steady State、Fault、Expected Degradation、Abort Condition和Recovery Assertion。Chaos Engineering需要预先定义假设、终止条件和恢复验证，不能仅执行无约束的Pod终止操作。

10. 恢复也要测

可靠性指标：

Detection Time：多久发现故障；
Failover Time：多久切换；
Recovery Time：多久恢复SLO；
Data Loss / RPO：丢多少数据；
Duplicate Side Effects：恢复时产生多少重复动作；
Backlog Drain Time：积压多久清完。

故障撤销后应验证Circuit恢复、连接池重建、Consumer继续、SSE重连、任务从Checkpoint恢复，而不是看到Pod重新Running就宣布大捷。

11. Agent性能指标

阶段	指标
Queue	Queue Wait、Admission Reject
Model	TTFT、Tokens/s、Input/Output Token、Cache Hit
Planner	Step Count、Replan、Loop Rate
Tool	Calls/Task、并发、P95、Error、Retry
Retrieval	Recall@K、Latency、Candidates、Context Token
End-to-End	Task P50/P95/P99、Success、Cost、Cancellation

Agent成本：

C_{\text{task}} =C_{\text{model}}+C_{\text{tool}}+C_{\text{retrieval}}+C_{\text{infra}}

优化不能只降Latency却让Task Success暴跌，也不能只提成功率让成本翻十倍。报告至少画Quality–Latency–Cost三维权衡。

Prompt Cache性能测试

固定角色与阶段路由Cache Key时，比较：

Hit Rate；
TTFT P95；
Prefill Token与费用；
错误命中或上下文串用；
Prompt版本变化后的失效率。

Cache Hit高但Tenant数据串了，不叫优化，叫高速泄密。

12. Agent负载场景

短问答：1次模型，无Tool
典型诊断：Planner + 2并行Agent + Synthesizer
长尾诊断：多轮Replan + 慢Tool + 大Context
失败风暴：Loki 429，模型Rate Limit，客户端重连
写操作：Approval等待 + Idempotent Execute

每种场景都应定义比例和Token分布。使用真实Trace的匿名样本生成负载，比固定的hello循环更能代表生产流量。

13. 性能门禁

PR阶段跑稳定Microbenchmark和小型Load Smoke；合并后跑代表性场景；夜间跑Stress/Soak；发布前跑容量与故障Case。

门禁示例：

Task Success 不下降超过 1pp
P95 不回归超过 10%
P99 < 45s
平均成本 < $0.05
Tool Error < 1%
无越权与重复副作用

阈值应基于SLO、历史基线和统计置信度确定，不能使用缺少依据的固定数值。

14. Agent辅助性能测试

Agent可以生成负载场景、分析Flame Graph与Trace、聚类慢请求、关联版本变化、提出实验假设。它不应自动把“CPU高”翻译成“加机器”，更不能未经审批在生产发Stress Load。

输入给分析Agent的证据要包含配置、时间窗口、样本量和基线；输出要求区分Observation、Inference和Recommendation。

15. 面试速答

Load和Stress区别

Load验证预期负载是否满足SLO；Stress持续推高，寻找容量极限和失败方式。

为什么看P99

平均值掩盖长尾；分布式链路多个阶段叠加后，少量慢调用会显著影响用户体验。

如何压测Agent

使用真实任务分布，分阶段记录Queue、Model、Tool、Retrieval、端到端质量、成本；同时验证安全和副作用不变量。