一、压测的目的
二、压测的完整流程
三、压测场景分析/组织测试脚本
四、压测数据准备
五、压测指标监控
七、压测结果分析
一、压测的目的
参考：https://cloud.tencent.com/developer/article/1048124?from=article.detail.1553360
1、需求缘起
场景：6月份的时候，浙里办要把预防接种放在浙里办的首页进行推广，问了我们几个问题：
（1）你们系统能支撑的最大QPS是多少？能抗的住推广吗？
（2）你们能支撑多大的并发用户数？
要回答这些问题，就要去评估现有系统的容量。那么我们怎么去评估一个系统的容量呢？
2、容量评估的步骤与方法
【步骤一：评估总访问量】
什么是总访问量？如何知道总访问量？对于一个运营活动的访问量评估，或者一个系统上线后PV的评估，有什么好的方法？
首先了解下PV、UV的概念：
PV（Page View）：页面访问量，即页面浏览量或点击量，用户每次刷新即被计算一次。可以统计服务一天的访问日志得到。
UV（Unique Visitor）：独立访客，统计1天内访问某站点的用户数。可以统计服务一天的访问日志并根据用户的唯一标识去重得到。
通常有以下几种方式：
1、询问业务方，询问运营同学，询问产品同学，看对运营活动或者产品上线后的预期是什么。
举例：58要做一个APP-push的运营活动，计划在30分钟内完成5000w用户的push推送，预计push消息点击率10%，求push落地页系统的总访问量？
回答：5000w*10% = 500w
2、对于已上线的系统，可以通过查看线上日志的方式得到总的PV访问量和每天的实时PV访问量曲线。
3、对于有系统限流的系统，可以通过限流设置知道系统的最大qps。
【步骤二：评估平均访问量QPS】
如何知道平均访问量QPS？
答案是：有了总量，除以总时间即可，如果按照天评估，一天按照4w秒计算。
举例1：push落地页系统30分钟的总访问量是500w，求平均访问量QPS
回答：500w/(30*60) = 2778，大概3000QPS
举例2：主站首页估计日均pv 300w，求平均访问QPS
关于峰值 QPS 计算方式，一般可参照 2/8 原则（供参考，并非一定）：
原理：每天 80% 的访问集中在 20% 的时间里，这 20% 时间叫做峰值时间
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
问：每天 300w PV 的在单台机器上，这台机器需要多少 QPS？
答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
TPS 即 Transactions Per Second 的缩写，指每秒处理的事务数量。一个事务是指一个客户机向服务器发送请求然后服务器做出回应的过程。
【步骤三：评估高峰QPS】
系统容量规划时，不能只考虑平均QPS，而是要抗住高峰的QPS，如何知道高峰QPS呢？
答案是：根据业务特性，通过业务访问曲线评估
举例：日均QPS为2000，业务访问趋势图如下图，求峰值QPS预估？
回答：从图中可以看出，峰值QPS大概是均值QPS的2.5倍，日均QPS为2000，于是评估出峰值QPS为5000。
说明：有一些业务例如“秒杀业务”比较难画出业务访问趋势图，这类业务的容量评估不在此列。
【步骤四：评估系统、单机极限QPS】
如何评估一个业务，一个服务单机能的极限QPS呢？
答案是：压力测试
在一个服务上线前，一般来说是需要进行压力测试的，以APP-push运营活动落地页为例（日均QPS2000，峰值QPS5000），这个系统的架构可能是这样的：
1）访问端是APP
2）运营活动H5落地页是一个web站点
3）H5落地页由缓存cache、数据库db中的数据拼装而成
通过压力测试发现，web层是瓶颈，tomcat压测单机只能抗住1200的QPS（一般来说，1%的流量到数据库，数据库500QPS还是能轻松抗住的，cache的话QPS能抗住，需要评估cache的带宽，假设不是瓶颈），我们就得到了web单机极限的QPS是1200。一般来说，线上系统是不会跑满到极限的，打个8折，单机线上允许跑到QPS1000。
【步骤五：根据线上冗余度回答两个问题】
好了，上述步骤1-4已经得到了峰值QPS是5000，单机QPS是1000，假设线上部署了2台服务，就能自信自如的回答技术问题了：
（1）机器能抗住么？ -> 峰值5000，单机1000，线上2台，扛不住
（2）如果扛不住，需要加多少台机器？ -> 需要额外3台，提前预留1台更好，给4台更稳
除了并发量的容量预估，数据量、带宽、CPU/MEM/DISK等评估亦可遵循类似的步骤。
二、压测的流程
需求调研、系统设计分析，系统链路梳理，总体方案设计，环境准备、脚本开发、数据准备、场景设计、场景执行、应用监控分析、瓶颈定位、瓶颈修复、回归测试、结果整理、输出报告等多个环节。
三、压测场景分析
参考博客：https://www.cnblogs.com/johnny-chen/p/13631159.html
从技术层面以及业务层面两个维度去进行思考划分：
性能场景设计方法步骤：
1.明确性能需求，确定业务应用场景
2.根据特定的应用场景进行业务场景建模（业务范围确认，业务操作流程，业务配比，思考时间，集合点等配置确认）
3.施压参数配置（梯度递增模式，瞬间加压模式，RPS吞吐量模式）
4.确认参数化数据，接口间参数关联
5.确认监控指标，启停标准，运行时间
压测的类型
分类：4大类
基准测试：单用户，发单次请求，产出基准性能数据。
负载测试：多用户，用户数渐增，持续同时发同一业务请求，产出最大TPS。
压力测试：多用户，资源使用饱和，持续同时发同一业务请求，产出系统瓶颈或使用极限。
混合场景测试：多用户，资源使用不饱和，持续同时发不同业务请求，验证系统稳定性。
四、压测数据准备
参考：https://sq.sf.163.com/blog/article/196036888966840320
一、性能测试数据准备
铺底数据准备
铺底数据有目的: 铺底数据的首要目的是让性能测试环境与线上保持一致，或者说接近线上真实情况。一个是保证待测系统有一定的规模，比如半年或一年后的用户规模。 另一个是为压测做准备，准备每个要压测的请求需要使用到的数据，这部分数据涉及到具体的业务，对性能测试结果影响比较大，具体说明可参考“参数化数据准备”章节。
根据以上两点，将铺底数据划分为两块：
只做铺底，在压测中不会访问到的数据，这部分数据是为了使数据库达到一定的规模，以发现数据库查询、更新等性能瓶颈，如忘记建立索引，查询SQL不合理等问题。只为铺底，压测时不会用到的这部分数据，在预设的过程中就比较随意了，不用考虑数据是否合理，也不用考虑业务关联关系，只要符合数据库设计规则，能插入数据库即可。
另一部分数据是在压测时要用到的数据，比如API要传参过去的数据，或者请求响应数据。这部分数据在铺底的时候就要精细化的设计，包括数据大小，数量，分布等。
铺底数据量多少合适？ 这个完全根据产品的规模来预估，比如产品预计半年后注册用户数达到100w，则铺底的时候需要铺底100w用户账号。 如果是已上线产品，根据线上数据库数据量进行预估，可以根据用户规模的比列进行铺底，如线上注册用户数一千万，线下铺底注册用户数100w，则总体数据规模为线上的十分之一左右。实际情况下，这里会略微复杂，比如还要考虑线上数据库集群和测试集群的硬件差异等，需做适当的调整。
参数化数据准备
如果我们从系统接口调用角度来看的话，参数化数据包括两类：一类是我们要传参给接口调用的数据，比如用户账号ID，商品ID等。 另一类是接口返回的结果数据，如获取商品详情时，需要返回商品的数量、颜色、描述信息等，这些数据必须是事先准备好的。
在进行参数化数据准备时，对于已经上线的产品，可以统计不同铺底数据的分布规律。从网易宝和之前的timeline的两个产品的数据统计来看，大多数数据的分布接近2/8原则。比如活跃用户数占注册用户数的比例为20%，非活跃或者欠活跃的用户占比为80%左右。针对具体业务，80%的业务是由20%的活跃用户产生，20%的业务是由80%的非活跃用户产生。所以参数化测试账号时，对这20%的用户账号需要进行精心铺底。
五、压测指标监控
参考博客：https://testerhome.com/topics/27409
关注的性能指标有哪些？关注的资源指标有哪些？如何监控这些指标？
六、压测结果分析
参考：https://testerhome.com/articles/21178
系统关键指标分析：
最大并发---上图未压测到最大并发
最佳并发----40左右
系统最大qps-----818.57
拐点-----未到拐点
应用cpu、内存
一般公司要求低于80%的利用率
jvm cpu、内存
数据库 cpu
3、数据库分析
