看我名字，其他不重要，你懂就好
功用测验针对系统的功用目标，建立功用测验模型，制定功用测验计划，制定监控战略，在场景条件之下执行功用场景，剖析判别功用瓶颈并调优，终究得出功用成果来评估系统的功用目标是否满意既定值。
一、功用测验中的目标
一切的技术目标都是在有事务场景的条件下制定的。
技术目标和事务目标之间也要有详细的换算进程。
举个比如：
论坛首要有以下几个功用点：注册、登录、发贴、阅读贴子、管理员可以单个或者多个的删去帖子，部分用户发贴需求经过审阅才能在前台展现；
咱们10万的活泼用户，每天线在用户数约为1W， 75%的用户阅读帖子(均匀5个帖子)并回复（2次），20%的用户会发贴（1个帖子）；而且以每个月5%的速度在增长；
咱们有30个各版块的管理员，每天80%的管理员负责审阅贴子（均匀每天20个），15%的管理员负责册除不符合要求或者过时的帖子（均匀每人删去3个） ；
用户发贴的思考时刻在5S~60S之间浮动，审阅帖子的思考时刻在 5S~20S之间浮动；每天晚上8时至12时是用户运用高峰期，早上9时 至10时是管理员审贴的高峰；
换算如下
1.1 事务目标
一切的技术目标都是在有事务场景的条件下制定的
功用目标表明法
1.2 技术目标
1.2.1 时刻目标
RT-呼应时刻：
接口/事务呼应时刻-从主张请求到接收到呼应的时刻。
1.2.2 容量目标
接口容量
接口的容量一般运用TPS/RPS来描绘。
事务容量
事务量一般由TPS目标来描绘，即系统每秒可以处理的事务量。
1.2.3 资源利用率目标
1.2.3.1 操作系统
CPU
IO
Mem
Disk
NetWork
1.2.3.2 JVM
GC
Classes
。。。
二、功用测验中的模型
在功用测验中，模型是对真实事务测验场景的笼统，用来描绘使用系统真实事务模型的样子。
举个比如，系统有 10 种事务场景，但并不是每个事务都需求有并发量，或许只要 5 个事务有，那就要把这些有并发的事务统计出来，哪个事务并发多，哪个事务并发少，做压力时就要控制好这样的份额。
获取用户行为形式的办法：
1、假如系统现已上线运转，则选用系统日志剖析法获取用户行为统计和峰值并发量等重要信息；
2、对于一个全新系统来说，一般是参考行业中类似系统的统计信息进行剖析和建模。
三、功用测验中的计划
计划规定的内容中有几个要害点，分别是测验环境、测验数据、测验模型、功用目标、压力战略、准入准出和进度危险。
测验环境：
1、测验环境需求尽量做到与线上环境装备保持一致，不然测验没有实际意义（不能反馈线上问题）
2、在大规模分布式系统中假如无法做到以生产一致，则需求剖析线上环境与测验环境的差异，经过核算得到相关的比值
测验数据：
测验数据需求依据用户行为模型以及当时系统的数据总量及分布批量生成
测验模型：
测验模型即相关的测验场景
功用目标：
呼应时刻
并发用户数
吞吐量
压力战略：
测验中用户的添加战略（如每隔1秒添加20个用户）
准入准出规范：
即系统需求经过功用测验之后才能做压力测验
压力测验系统相关的目标达到需求规范后即可完结测验
进度危险：
反馈测验进程中发现的潜在系统危险，如压测环境与线上环境不同较大、某一项系统目标呈现异常
四、功用测验中的监控
功用测验中需求有系统监控，系统监控要有分层、分段的才能，既要有大局监控也要有定向监控的才能。
功用测验剖析的才能阶梯视图：
1、东西操作：包含压力东西、监控东西、剖析东西、调试东西。
2、数值了解：包含上面东西中一切输出的数据。
3、趋势剖析、相关性剖析、证据链剖析：便是了解了东西产生的数值之后，还要把它们的逻辑联系想明白。这才是功用测验剖析中最重要的一环。
4、最后才是调优：有了第 3 步之后，调优的计划战略就有很多种了，详细选择取决于调优成本和产生的作用
功用剖析思路：
1、瓶颈的精准判别
1.1 TPS曲线
当添加压力tps的递加比之前要小，呼应时刻却在添加的时分，瓶颈或许就呈现了。
经过TPS曲线可以判别系统是否存在瓶颈，瓶颈是否和严厉有联系，若经过不断添加压力 tps都会呈现相同的趋势时，瓶颈就和压力无关，不然便是有联系。
1.2 呼应时刻曲线
ttps曲线才是用来判别系统是否有瓶颈的，呼应时刻只是用来描绘事务的快慢。
2、线程递加的战略
压力的递加战略有必要符合实际事务场景，即使是在秒杀场景中压力也是递加的不会一开端就上全部并发线程。
在做系统压力测验中，仅在改动压力战略（其他的条件比如环境、数据、软硬件装备等都不变）的状况下，系统的最大 TPS 上限一般来时是固定的。
在递加战略测验进程中，若每次添加压力tps都会呈现抖动的状况，则有或许是以下两种或许：1、资源的动态分配不合理，如后端线程池、内存、缓存等；2、测验没有进行数据预热。
3、功用衰减的进程
当每一线程每秒的 TPS 开端变少时（总的tps还在添加），阐明功用瓶颈现已呈现了
当系统瓶颈呈现后，系统的处理才能（TPS）并不会立刻下降，TPS依旧会缓慢添加，此时系统功用正在衰减，tps终究达到上限。
4、呼应时刻的拆分
在系统压力测验进程中，当系统达到了瓶颈，再继续添加压力，呼应时刻就一定会上升，直到超时为止。
拆分呼应时刻是为了进一步承认时刻首要消耗在哪个模块。
在分布式使用系统中主张运用链路的监控东西来拆分时刻。
5、构建剖析决策树
构建剖析决策树是对系统架构的整理，是对系统的整理，是对问题的整理，是对查找证据链进程的整理，是剖析思路的整理。
剖析决策树起到的是纵观大局，高屋建瓴的指导作用。
其间RDBMS 中的 MySQL的决策树如下：
操作系统的剖析决策树如下：
剖析决策树的意图是为了找出系统呈现系统瓶颈的终究原因。
剖析决策树协助咱们在剖析系统瓶颈时供给证据链查找思路。
功用测验的终究意图是发现造成系统瓶颈的问题点，并能经过各种手段进行优化是系统处于最优状态。
6、场景的比对。
当你觉得系统中哪个环节不可的时分， 又没才能剖析它，你可以直接做该环节的添加。
可以经过添加其间一台使用服务器或者添加压力机的方法，经过比照测验成果定位问题。
五、功用测验中的场景
基准功用场景：这里要做的是单交易的容量，为混合容量做准备。
容量功用场景：确认系统可处理同时在线的最大用户数，使系统承受超额的数据容量来发现它是否可以正确处理。
稳定性功用场景：稳定性测验必定是功用场景的一个分类。在稳定性测验中，明显最核心的元素是时刻（事务模型现已在容量场景中确认了），而时刻的设置应该来自于运维周期，而不是来自于老板、产品和架构等这些人的心理安全感。
异常功用场景：要做异常功用场景，条件便是要有压力。在压力流量之下，模拟异常。
六、功用测验中的剖析调优
功用项目分类
新系统功用测验类：
新的项目常常需求测验出系统的最大容量，系统上线能抗住多少并发拜访，上线前还需求将系统调至最优状态。
对与现已在线运转的系统：一般都是和旧版别做功用比照，确保新版班功用不会低于历史版别，对调优要求一般都不大。
七、功用测验中的成果陈述
在功用测验陈述中应该着重表现一下两点：
1、功用测验的成果（是否存在瓶颈，假如存在导致存在的瓶颈的问题是什么）、是否满意发版需求
2、调优前后的 TPS、呼应时刻以及资源比照图。
