案例中 826ms 的连接池等待是如何被定位和解决的？

某 APP 用户投诉"页面加载特别慢"，客户端反馈接口响应超过 1 秒甚至 2-3 秒，但后端监控显示接口处理稳定在 400ms 左右——典型的"客户端服务端数据对不上"困境。通过 RUM SDK 的 timing_data 字段精准定位问题：原始数据显示总耗时 duration = 1232.8ms，没有 DNS/TCP/SSL 回调说明使用了连接池复用，但 callStart 到 connectionAcquired 的间隔高达 826ms，占总耗时的 67%！这表明问题不在 DNS、TCP 或 SSL 握手，而是等待连接池分配连接的时间过长。逐阶段验证：发送请求头 2.14ms、发送请求体 0.70ms、服务器处理 402.46ms（与后端日志吻合）、接收响应头 0.41ms、接收响应体 0.13ms、连接释放 2.26ms，所有其他环节都很正常。根因诊断：应用使用的是 OkHttp 默认配置，ConnectionPool 只有 5 个空闲连接，在并发请求多时大量请求排队等待连接释放。优化方案：增加连接池容量到 30 个（new ConnectionPool(30, 5, TimeUnit.MINUTES)），同时调整 Dispatcher 的 maxRequestsPerHost 到 10（默认为 5）。