适用场景

容量规划最容易犯的错是「等报警再扩容」。正确做法是用最小成本算清三个数：当前单机能扛多少、业务每周涨多少、扩容需要提前多久。三个数齐了，扩容就是例行动作。

配置步骤（压测标定与拐点识别）

# 1) 压测工具（示例：wrk）
wrk -t8 -c200 -d300s --latency "http://target/api/list?page=1"

# 2) 观察指标（压测中同时采集）
#    QPS、P95/P99 时延、错误率、CPU/内存、DB 连接数与慢查询

# 3) 找拐点：逐步加压
#    并发 50 -> 100 -> 200 -> 400，记录 QPS 与 P95
#    当 P95 明显抬升而 QPS 不再增长，即为拐点，取拐点 70% 作为单机能力

# 4) 压测纪律
#    - 环境与生产一致（规格/配置/数据量级）
#    - 压测数据隔离，避免污染生产库
#    - 压测前通知，避免与备份/批处理叠加

# 5) 结论归档
#    单机能力、瓶颈点（CPU/DB/连接池）、优化建议

关键参数与建议

  • 单机能力：用压测标定（QPS、并发、时延拐点），不要用经验值
  • 增长模型：按周环比推月，大促与新业务上线显式纳入
  • 瓶颈顺序：CPU → 内存 → IO → 网络 → 连接数/队列，逐项验证
  • 扩容触发线：核心 60% 预警、75% 申请、85% 强制；非核心可放宽
  • 提前期：采购+上架+部署+数据同步的总时长要写进台账
  • 成本替代：索引优化、缓存、异步化往往比扩容便宜，优先评估
  • 压测纪律：压测环境与生产配置一致，压测数据隔离
  • 复盘：每次大促后更新单机能力与增长模型参数

容易踩的坑

  • 压测环境规格低于生产，结论不可用
  • 压测库数据量只有生产的 1%，数据库瓶颈测不出来
  • 只压单接口，忽略组合场景与依赖
  • 压测期间跑备份，数据被污染
  • 没有拐点分析，只记了一个 QPS 数字
  • 压测结论不归档，扩容时又拍脑袋

验证与巡检

# 压测结论必备数据
# 并发 | QPS | P95 | P99 | 错误率 | CPU | 内存 | DB 连接
# 拐点并发与拐点 QPS

# 复测：每次大版本上线后复测一次
  • 巡检：压测报告含拐点数据、瓶颈点明确、大版本后已复测

小结

容量模型验收：业务量翻倍时能立刻回答「哪些资源要扩、扩到多少、多久到位、花多少钱」，四项都有数字。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。