业务压测设计的心得

很久没更新博客了，原因是……本地有notebook整理资料，processon云工作文档，还有本地导图，各种文档，说实话维护不过来了，应该有一种方式，无感知的积累知识、心得、工作，而不是博客这样刻意去发布。说说正题压测吧  

压测方案：如果你没做过压测，可能想的是jmeter、代码脚本开发、各种日志数据排查、压力点分析、统计报告等等……这些都是执行的事，实际上更多还是对业务、服务的调研，结合测试技术、开发技术，综合考虑的一个能发现性能问题的低成本的可执行方案。

压测业务链：一般是从某种业务场景开始，分析业务走向，确定链路。确定业务走向后，就可以确定涉及哪些服务，调用方式，数据处理，持久化，数据库事务等等，基本就确定了压测要观察的对象。

压测入口：一个业务链的节点很多，可以从业务入口切入施压，也可以从中间。大部分都会模拟业务入口去施压，一个是更贴近真实的业务场景，再一个暴露的问题更全面，当然对开发配合和效率也要求更多，问题越多，对分析能力，解决效率自然要求就高了。施压入口提前，也便于测试模拟执行，有很多执行方式可选。

压测压力：一般都说多少并发量，比如1000并发量，那么问题来了，是每秒1000次，还是每毫秒1000次，还是微妙……再一个是平均分布，还是一秒的第一刻或最后一刻爆发1000次，之后的一秒间空闲。或者是模拟1000个用户，定义请求频率和持续时间。总之你得弄明白你要施压的模拟压力应该是什么，正常来说TPS或QPS来描述压力是相对统一的概念。

压测实施：这里头就各式各样都有了，终归是能有效解决问题就行，不拘泥于高深浅显技术。是人工执行，工具执行，还是自己开发代码执行，或者统计生产的用户高峰数据，都是一种手段，只要是符合你设计的压测方案，模拟压力符合，而且成本可接受，都是可以的。

压测报告： 出性能曲线，找出拐点，给出优化后的QPS，找到或解决了哪些压力点