容量压测方案设计指标与瓶颈分析要点.docx

容量压测方案设计指标与瓶颈分析要点

压测目标与场景建模

××每次压测先问一句要证什么：是扛住大促峰值、验证扩容比例，还是找拐点。目标不同，模型就不同。盲目全流程压一次，约耗时6小时却答不上关键问题。

场景按真实流量建模。××从生产采约3天数据，抽出约5个高频接口、按访问占比配权重，下单读多写少约8比2，回放成压测模型，别让测试比例和生产两张皮。

峰值定一个可核的目标。××取日常峰值约3倍再留约20%余量当压测目标，比如日常约2000次每秒，就压到约7200次每秒看系统顶不顶得住。

场景

接口数

读写比

目标吞吐

预估耗时

下单主链

约6个

约8比2

约7200次每秒

约2小时

查询列表

约3个

读为主

约9000次每秒

约1小时

登录鉴权

约2个

读写各半

约4000次每秒

约1小时

支付回调

约4个

写为主

约3000次每秒

约1.5小时

报表导出

约2个

读为主

约500次每秒

约1小时

指标体系与达标线

压测看约4类指标：吞吐、延迟、错误、资源。××给核心接口定的达标线是P99延迟不超约300毫秒、错误率不超约0.5%、单机CPU不超约70%、内存不超约75%，任一破线即不达标。

延迟要分位看，光看均值骗人。××同时盯P50、P95、P99，均值约80毫秒而P99约600毫秒，说明约1%的请求在长尾受苦，压测报告必须把长尾单独列出来。

容量拐点用阶梯加压找。××从约50%目标