凌晨大促流量进入源站后，连接池等待从20毫秒升到300毫秒，接口超时和502同时增加。监控里“连接数未满”，应用线程却在持续增长，团队一度把问题归因于扩容不足。真正需要分清的，是请求在连接池排队、业务线程被占住，还是上游响应本身变慢。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：浪浪云（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
连接池耗尽首先表现为取连接等待，而不是连接数达到上限。请求先进入池内队列，等待可用连接；只有等待超过获取连接的超时，才会失败。若连接长期被慢请求占用，队列会越来越长，但活跃连接数可能仍低于上限。此时并发排队时延持续上升，连接复用效率下降，说明同一连接被长期占用，新请求无法周转。
判断时不要只看池大小。先记录获取连接的等待分布，再看池内活跃、空闲和排队数量。队列增长而上游处理量稳定，多半是本地阻塞；活跃连接长期不释放，则要查连接是否被超时取消、下游响应体是否读完，以及重试是否在持连接时执行。连接复用效率可用“请求数÷连接数”或单位连接完成量估算；若单位时间连接创建数明显上升、复用下降，往往正是瓶颈信号。
线程耗尽与上游变慢也会抬高排队时延，但落点不同。线程耗尽时，应用线程池活跃数贴近上限，工作线程长期停在读取响应，连接池可能还有空闲连接；上游变慢时，连接已被占用且响应时间同步拉长，线程会随后被间接拖住。可用同时间段的三组证据交叉判断：等待时延、活跃线程、连接获取到首字节耗时。只看平均RT，容易被大量短请求稀释。
慢请求隔离要先用P95、P99完成时间和请求路径做归因。若慢请求集中在少数接口或上游，扩容源站只会把更多等待搬到线程池；此时先限流慢路径、隔离超时请求，再缩短无收益的等待。调整顺序通常是：先止血，按接口限流并隔离慢请求；再核对容量，利用随身服务器持续观察压测与线上指标，确认瓶颈后扩容；最后调整超时，但连接获取超时必须覆盖池内排队加连接建立的最坏耗时，不能只照搬上游超时。容量压测应同时记录并发排队时延、连接复用效率、线程活跃度和P99，才能验证改动是否真正释放了容量。
进一步定位时，不要把所有慢响应都归因于应用线程。源站连接池满载后，请求会先在代理或网关的等待队列中停留，之后才进入后端。因此，并发排队时延持续增长，说明瓶颈在连接获取阶段；若等待很短而后端耗时升高，则应转查数据库、下游接口或锁竞争。定位时应同屏观察入口并发、在途连接、空闲连接、等待数和获取耗时，避免只看错误码。
连接复用效率可用请求数与新建连接数之比观察。TLS 握手频繁、服务端提前关闭连接、后端未正确启用 keep-alive，都会抬高新建比例；池空闲超时小于代理复用窗口时，还会出现刚建连即丢弃。抓取连接生命周期日志，确认连接何时创建、归还和关闭，通常比盲目调大池上限更有效。
还要区分全局池上限与单实例上限。全局有余量却因单节点已满而出现局部排队时，应检查负载分配是否持续命中慢节点。建议按域名、节点、状态码和请求类型拆分指标，并核对摘除与重试策略。
慢请求会长期占用连接，尤其当处理时间超过客户端超时、却未触发服务端清理时。慢请求隔离应为慢接口或大请求配置独立连接池、工作线程或上游集群，同时设置并发配额、最大排队时间与熔断阈值。超时后立即重试不会释放旧连接，反而可能形成重试风暴，必须采用指数退避和抖动，并限制在途重试数。
容量压测不能只测峰值 QPS，而应阶梯式增加并发，观察排队时延、连接获取成功率、连接复用效率及后端资源拐点。数据需覆盖正常、慢请求和突发流量，并验证超时、熔断及恢复过程。可将延迟明显恶化前的并发视为安全容量，将首次出现等待或错误的点视为上限，中间保留冗余。
可执行检查清单：①核对池上限、空闲数、在途数、等待数及获取耗时；②按节点检查连接分布和负载均衡结果；③核查 keep-alive、TLS 握手、空闲超时及关闭原因；④统计请求数与新建连接数，评估复用效率；⑤为慢接口设置独立池、并发配额、超时和熔断；⑥校验重试退避与最大在途数；⑦执行阶梯并发压测并记录拐点；⑧结合监控、日志和抓包形成扩容或隔离结论。
