互联网听说过压测这个词的孩子可能头发都不多了，原因不多说，需要熬夜的事情必然有些牺牲，例如头发。
为啥要头发会少？因为压测要避开高峰期进行，所以，低峰期就是用户休息的时候，现在用户睡的越来越晚，那么压测的时间越来越接近凌晨。
那么聊聊压测：
常见的压测两种性能测试的压测：
业务负载：功能没有问题的时候，进行性能测试
接口压测：对接口进行压测
性能测试的选择：
和需求有关，选择的场景不同，使用的性能测试方案均是不同的，性能是随着业务的发展，不断新的要求，不同的阶段，性能测试的频率不一样。
例如之前有个馒头的例子：
一口气吃十个馒头，并发，压力（并发）测试，一口吃15个，20个，吃不下，一口吃18，能吃；
馒头一个一个吃，负载测试；（压死骆驼的最后一根稻草）
如果这个人知道能吃15个馒头，绕操场跑，如果没问题，就是稳定性很好。
二、压测这么重要，那怎么准备？
1、目标定位：为啥要压测？压测目标？对线上有什么影响？系统是否支持压测？下游是否支持压测？怎么评估压测的结果？压测的方案怎么写？为啥这样写？准备什么时候压测方案评审？这些都是要特别明确的问题。
2、关于压测改造的部分：
埋点的优化：是否可以满足查看压测场景的需求
压测逻辑的改造的合理性：改造是否合理，是否有风险（如果压测流量标识丢了会怎样，带来怎样的影响），是否灵活；在确定具体mock的性能时和被mock模块确认性能，使得mock贴近于真实反映性能，在针对下游有mock逻辑时，需要知道mock逻辑和真实逻辑的区别；
3、压测链路下游和线上的真实性：对于下游业务方逻辑是黑盒，需要确定压测流量的数据是否能真实的反映线上对应接口的性能。
数据的准备工作：
1、区分环境梳理全链路用到的数据：prod、test环境的数据准备都需要考虑，考虑的维度不仅是用户请求参数的数据，还包括请求过程链路中用到的信息；
2、下游压测数据的check：请求下游的数据需要和下游确定数据的使用和偏移情况，压测数据是否可以达到反映下游性能的预期；
3、数据的全面性和易观察性：数据是否能真实反映业务，数据结果是否易于业务监控和识别压测结果。
压测计划的设计：
1、下游性能和依赖评估：对于下游业务方逻辑是黑盒，梳理遗漏点，同时要了解是否有基础组件的操作，例如对缓存、数据库等是否有读写的操作，对下游的QPS的值和影响的评估；
2、压测配置checklist完备清晰：设计压测方案各种开关配置等建立checklist，过程中虽然繁琐，但是后期看的时候一目了然；
3、场景完备且互斥：场景的不同在压测过程中都应覆盖到，不能想当然就遗漏场景；
4、慎重对待不清楚的问题：压测每个细节都要考虑，思路要清晰，不要想当然，看文档啥的都来的不够真实，代码配置的是什么才是什么。
压测的验证：
1、完整多维度check链路：check的时候，除了check链路，还需要check真实表、影子表、真实缓存、影子缓存等情况，涉及到的开关和配置都需要验证，并不是开了、配置了就行；
2、验证操作谨慎操作：st验证时候当成线上验证，遵守压测规范；
3、线上线下验证一致性：线上线下验证的时候保证配置的一致性，影子开关、数据库表等都需要一致；
4、问题排查要彻底：遇到不清楚的问题，不要想当然的猜测以免误导，要去问原因；
具体实施：
1、小心操作：压测执行的每个按钮按的时候思考7秒再操作；
2、发现报警及时停止压测，确定没有问题后再重新压测，不要存在侥幸心理；
3、观察监控、机器指标、业务监控、报警情况；
4、压测的报告要仔细分析，后续的TODO要跟进；
5、线上压测方案需要审核的提前执行到待启动压测方案那一步。
压测就介绍这么多吧，突然的结束，有同学评论或者点击在看后，继续更新！预览时标签不可点收录于话题#个上一篇下一篇