服务网格压测先看连接池拐点
后端架构先看边界和失败路径，再看吞吐数字。这篇只讨论一个问题：服务网格压测先看连接池拐点。
写作边界：围绕“服务网格压测先看连接池拐点”出现的数字、事故场景和性能结果均用于演示分析方法，不是特定项目的实测结论。落地时请记录版本、输入、资源、统计窗口和失败路径，再用自己的测试数据复核。
从延迟拐点追到 Envoy 连接池
报告再长，也先回答三个问题：吞吐在哪个负载阶段停止增长，P99 从哪里开始抬头，CPU、连接等待与排队长度是否同步变化。CPU 不高但尾延迟突然变差，通常意味着请求卡在连接池、队列或下游 I/O，不能直接归因于算力不足。
服务网格场景可继续对照 Envoy 的upstream_cx_overflow、upstream_rq_pending_overflow和活动连接数。大模型流式请求持有连接更久，沿用普通短请求的连接池参数，容易让新请求长时间排队。
调整时一次只改一个变量：先固定请求长度与并发模型，再比较连接上限、Pending Queue 和 HTTP/2 多路复用策略。入口限流也应考虑预估 Token，而不是只数请求。每轮都保留相同负载下的吞吐、TTFT 分位数和错误类型；曲线恢复后，再决定是否扩大灰度范围。
落地检查
- 固定“服务网格压测先看连接池拐点”涉及的输入、版本、流量模型与统计窗口，再比较变更前后。
- 对自动化动作设置权限、超时和熔断；失败时回到可解释的确定性路径。
- 把结论连同原始日志、指标截图和回滚条件一起归档，避免只留下口头判断。