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