云联信息：压测不是跑个数字，是找瓶颈
一、先定义什么叫扛得住
是支持一千人同时在线，还是每秒处理两百个订单？指标不同，压测方式完全不同。先把业务指标翻译成技术指标：并发数、QPS、响应时间。
二、场景要贴近真实
只压首页没意义，用户实际会登录、搜索、下单。按真实路径设计脚本，比例也要接近真实分布。
三、逐步加压而不是一步到位
从低并发开始，每轮增加一定比例，观察响应时间和错误率的变化。找到曲线开始变陡的拐点，那就是当前架构的极限。
四、四个指标要一起看
QPS、平均响应时间、错误率、资源使用率。只看QPS，会忽略响应时间已经恶化；只看资源，会忽略瓶颈在数据库。
五、瓶颈通常在三个地方
数据库连接、应用线程池、网络带宽。压测时同步观察这三项，多数瓶颈能直接定位。找到瓶颈再优化，比盲目扩容有效。
六、压测环境要隔离
在生产环境压测会影响真实用户，在测试环境压测又可能配置不同。比较稳妥的是用生产同配置的独立环境，数据脱敏后使用。
七、注意压测机本身的限制
压测机的带宽和连接数可能先到瓶颈，导致测出来的结果偏低。压测机与被测系统的资源都要监控。
八、结论要落成容量规划
压测结果是容量规划的输入：单机能扛多少，需要几台，扩容阈值设在哪里。没有结论的压测，只是一次性能表演。
九、定期复测
代码更新、依赖升级、数据量增长都会改变性能表现。每季度复测一次，容量规划才跟得上实际。
压测数据要接近真实量级
表里只有一万条数据，压出来的性能没有参考价值。按生产数据量级准备测试库，索引和数据分布都要一致，否则结论会过于乐观。
关注长尾响应时间
平均响应时间好看，但百分之一的请求要五秒，用户照样会抱怨。压测报告里要有P95和P99，比平均值更能反映体验。
限流和熔断要一起设计
压测找到极限之后，配套做限流和熔断。超过阈值时优雅拒绝，而不是整站雪崩。保护系统的能力，比提升峰值更重要。
容量规划要留缓冲
按压测极限的六成设置扩容阈值，留出应对突发和单机故障的余量。贴着极限运行，任何波动都会变成故障。
压测报告要给业务方看
报告里少放技术参数，多放结论：现在能支撑多少用户、什么时候需要扩容、扩容到什么规格。业务方看得懂，容量规划才能真正落地。
云联信息【资深云服务专家微信：cloud7591】提醒：任何一次变更都要能在十分钟内回滚，否则不要挑业务高峰动手。