容量规划需通过压测闭环验证真实瓶颈而非拍脑袋定值；须基于业务流量基线设定目标，分吞吐压测、稳态验证识别轻负载临界点与稳定性，排除压测机、下游依赖等假瓶颈，最终按70%折算并叠加冗余得出单机安全容量。
容量规划中评估单台服务器的极限承载能力，不能靠拍脑袋或查配置表，必须通过压测工具（如 JMeter）做闭环验证。核心不是“跑出一个最大数字”，而是“在可控条件下，识别系统真实瓶颈并反推安全容量边界”。
明确压测目标和业务锚点
压测前先锁定两个关键输入：
- 真实业务流量基线：从线上日志或监控平台（如 Prometheus + Grafana）提取最近 7 天高峰时段的接口 QPS、平均请求体大小、读写比例、热点数据分布等。例如某下单接口白天峰值为 1200 QPS，P95 响应时间 380ms，错误率
- 可接受的服务水位线：不是“不挂就行”，而是定义 SLO。例如：CPU ≤ 75%，内存使用率 ≤ 80%，P99 响应时间 ≤ 800ms，错误率 ≤ 0.5%。这些是判断“是否已达极限”的标尺，而非单纯看 TPS 上不去。
设计分层递进的压测模型
单台服务器压测要避免“一步到位”，推荐三阶段推进：
- 基线摸底（并发模式）：用 JMeter 线程组模拟 100–500 并发用户，Ramp-Up 控制在 60s 内，观察系统响应时间拐点。重点记录 CPU、JVM GC 频次、数据库连接池使用率。此时若 P95 跳升 >200ms 或错误率突增，说明已触达轻负载临界点。
- 吞吐压测（RPS 模式）：切换为 Throughput Shaping Timer 或 Arrivals Thread Group，以 200 QPS 起步，每 2 分钟+100 QPS，持续加压至出现指标劣化。记录每个档位下的实际达成 QPS、平均 RT、服务端资源占用。当 QPS 增长停滞甚至回落，而 CPU 已达 85%+、GC 时间占比超 15%，即为吞吐瓶颈点。
- 稳态验证（Soak Test）：在上一阶段确认的“准极限值”（如 2400 QPS）下，持续运行 30–60 分钟。重点检查内存是否缓慢上涨（疑似泄漏）、线程数是否持续堆积、数据库慢查询是否激增。稳定才可作为上线容量依据。
识别真瓶颈，区分假瓶颈
JMeter 报告里 TPS 卡住，不等于服务器到极限了。常见干扰项包括：
- 压测机自身瓶颈：单机 JMeter 模拟超过 800–1000 线程时，本机 CPU/网络/端口耗尽，导致发不出请求。此时看 JMeter 日志是否有“Connection reset”或“Too many open files”，需改用分布式压测或换用 k6 等轻量工具验证。
- 下游依赖拖累：比如 DB 连接池只有 50，而应用线程数设为 200，大量线程阻塞在 getConnection()。应同步监控 MySQL 的 Threads_running、Redis 的 connected_clients，排除外部限速。
- 应用层低效逻辑：JVM 出现频繁 full GC、代码中存在同步块或大对象序列化、未使用连接池等。用 jstat、Arthas 或 Profiler 抓取热点方法，比只看 TPS 更能定位根因。
反推单机安全容量
极限值 ≠ 安全值。建议按如下方式折算生产可用容量：
- 若压测得出“稳定支撑 2600 QPS（P99=720ms，CPU=78%）”，则日常容量建议设为 2600 × 0.7 ≈ 1800 QPS；
- 若系统有明显波峰波谷（如电商午间高峰），再叠加 1.5–2 倍冗余应对突发；
- 最终单机容量 = min(计算值, DB/缓存/中间件单节点上限)，例如 Redis 单实例推荐 QPS ≤ 5 万，那应用层再高也没意义。
本质上，JMeter 是把服务器当成黑盒打，而容量规划需要打开盒子看哪一层先扛不住——然后把那个“最先喘不过气”的位置，定为你的硬边界。
