用 Little's Law 算线程池/连接池大小时，驻留时间 R 到底该代入「端到端 P99」还是「下游 RT 之和」？两者差 3 倍（含排队时间），选错会把池算偏多少？

背景 我在给一个 Java IO 型聚合服务做容量评审：单 Pod 8C，入口稳态 500 QPS、峰值 ~1000 QPS，单请求链路是「Tomcat 工作线程 → 并行调 3 个下游（MySQL P99 12ms、Redis P99 2ms、第三方 HTTP P99 380ms）→ 聚合返回」。下游连接池 HikariCP max=20、Redis 池 max=30。我想用 Little's Law（L = λ × R）把「Tomcat 工作线程池」和「HikariCP 池」都定量算出来，而不是拍脑袋。

卡点（现象） 算 L 时那个 R（驻留时间）我拿不准，团队里两种算法差出 3 倍：

• 算法 A：R = 下游 RT 之和的 P99 ≈ 380ms（HTTP 是并行里的长板，取 max 而非 sum，约 400ms 量级）
• 算法 B：R = 端到端请求 P99 ≈ 1.1s（含线程排队、GC、序列化、网络抖动） 按 500 QPS 算：A 得 L≈200，B 得 L≈550。直接决定线程池是配 200 还是 550，差了将近 3 倍，资源差一大截。而社区里既有人用「下游 RT 之和」（文 1556 的 17 个连接池推导），也有人强调「按端到端 P99 配超时」（讨论 1459 里 P99 锚点的争论），两边都没把「R 到底含不含排队时间」说死。

已尝试的排查与结果

1. 我按算法 B 把线程池配到 600，压测到 900 QPS 时发现：HikariCP pending 线程开始堆积、端到端 P99 反而从 400ms 飙到 900ms——疑似「加线程 = 加雪崩」（类似文 76 里 200→2000 P99 翻 5 倍的现象），说明线程池不是越大越好。
2. 我怀疑真正的瓶颈不在线程池而在下游 RT 的 P99 方差：第三方 HTTP 的 P99 是 380ms，但 P99.9 可能到 1.2s，用 P99 定 R 会把长尾吃掉。
3. 我也没想清楚：并行调用 3 个下游时，线程被「占住」的时间到底是「最慢那个下游的 RT」还是「全部 RT 之和」？如果是并行且共享线程，占位时间应该取 max（≈400ms），但 Little's Law 的 R 又像是「一个请求从进系统到出系统」的总时长（含排队），这两者怎么统一？

期望得到的答案形态 希望有人给一个可复现的判定规则，而不是「看情况」：

1. Little's Law 里的 R 到底该代入「下游 RT（取 sum 还是 max，取决于串行/并行）」还是「端到端 P99」？两种代入分别对应哪种资源（线程池 vs 连接池）的容量？
2. 排队时间（queuing delay）该不该算进 R？如果该算，怎么避免「用含排队的 R 算池大小，池又反过来决定排队时间」的循环依赖？
3. 给一个带具体数字的算例：比如上面这组参数（500 QPS、下游 12/2/380ms、目标 P99 预算 500ms），线程池和 HikariCP 各该配多少，以及为什么。
4. 最好附一条「R 用 P99 还是 P99.9、长尾怎么兜」的避坑清单。