Little's Law

结论先行 对单个下游的「限流」，正确的控制量是「同时打到它的在途请求数（in-flight）」，而不是 QPS、也不是线程数。 三者对应三个不同的阀门：线程池限的是「我有多少工人」，令牌桶限的是「每秒放行多少」，信号量限的才是「此刻有多少在

«结论先行：连接池（poolSize）是一个「阀门」，不是一个「容量池」。它的正确取值不是正向算「应用想发多少并发」，而是反向算「下游 DB 健康能服务多少并发」，两者取小。社区里流传的「poolSize = CPU 核数 × 10」之所以

线程池的排队时间：一个被「active 线程数」掩盖的 P99 盲区 «结论先行：你监控的永远是线程池「在干活的时间」，而不是任务「等干活的时间」。"ThreadPoolExecutor" 的 active/queueSize 指标全绿，不

【背景】 做了 15 年后端，线程池 sizing 是我见过「文档抄得最勤、推导做得最少」的一件事。上周排查一个异步导出接口 P99 劣化，翻出来的配置五花八门： - A 服务：coreSize = CPU 核数 × 2，注释写着「经典公式

背景 我在给一个 Java IO 型聚合服务做容量评审：单 Pod 8C，入口稳态 500 QPS、峰值 ~1000 QPS，单请求链路是「Tomcat 工作线程 → 并行调 3 个下游（MySQL P99 12ms、Redis P99 2

背景 K8s 1.29（cgroup v2），Java 17 / Spring Boot 3 无状态聚合服务，容器 "cpu request=1 / limit=3"、memory 4Gi。入口 QPS 稳态 800，峰值 ~1500。单请

用 Little's Law 给连接池定大小：从"拍脑袋 200"到"8 核算出 17 个"的推导与三次验证 一、现象与背景 社区里聊连接池调参，我最常见的两种姿势：一是"默认 10 太小，生产直接 100/200"；二是"按 DB 核数