前言 全链路压测可以说是大促前必经的一个过程，为了确保链路的稳定以及应对大促期间可能因为流量激增引发的所有问题。作为职场新人的我也是在前段时间有幸参加了部门的双旦(圣诞+元旦)大促压测，今天便和大家分享一下自己的一些压测心得。
一、什么是压测
1.1概念
压测，即压力测试，是确立系统稳定性的一种测试方法，通常在系统正常运作范围之外进行，以考察其功能极限和隐患。 一般针对系统服务器不断施加“压力”的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
1.2 压测的参考指标
即是要进行压测，肯定是有一些指标用于我们判断系统的承载能力。
TPS
TPS 即Transactions Per Second的缩写，每秒处理的事务数目。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程 (完整处理，即客户端发起请求到得到响应) 。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息作出的评估分。一个事务可能对应多个请求，可以参考下数据库的事务操作。
QPS
QPS 即Queries Per Second的缩写，每秒能处理查询数目，即每秒的响应请求数。是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。但实际上，现在习惯于对单一接口服务的处理能力用QPS进行表述（即使它并不是查询操作）。
平均处理时间（RT）
RT：响应时间，处理一次请求所需要的平均处理时间。
RT99：99%请求的的平均处理时间
TP指标
TP: 指在一个时间段内，统计该方法每次调用所消耗的时间，并将这些时间按从小到大的顺序进行排序, 并取出结果为 ： 总次数 * 指标数 = 对应TP指标的序号 ， 再根据序号取出对应排序好的时间。
-
TP90，top percent 90，即 90% 的数据都满足某一条件；
-
TP95，top percent 95，即 95% 的数据都满足某一条件；
-
TP99，top percent 99，即 99% 的数据都满足某一条件；
CPU使用率：
一段时间内CPU的使用状况，从这个指标可以看出某一段时间内CPU资源被占用的情况。
Load Average：
某一段时间内，CPU正在处理以及等待CPU处理的进程数的之和。Load Average是从另一个角度来体现CPU的使用状态的。
1.3接口的限流设置
一般对于我们服务端的开发同学来说，全链路压测到自己负责的系统，一定要保证好系统的稳定，设置接口限流是必不可少的关键。
假设每秒10000的qps，分别打在A、B两个机房。流量比为4:6。
10000qps ——> A:4000 B:6000
单机qps： 6000/8 = 750 qps 这样即可将单机单接口的qps限流值设置为750。
二、压测问题分析
2.1压测问题分析
常见的压测问题有很多：
1、个别服务流量过大分析。
2、依赖服务超时异常过高
3、流量压测cpu表现不均匀
4、查询接口超时严重
5、限流方案
6、压测qps上不去，但是各项监控指标正常
我主要分析其中一个比较常见的：
本地RT上涨、RPC请求成功率下降,也就是查询接口超时 先来看一副案例图
-
这是一张本地服务TP图
-
这是一张远程服务TP图
可以看出远程服务响应时间大多在100-200ms左右，然而本地服务响应时间却已经高达660ms左右，甚至部分请求高达800ms。
由此可知： 压测流程激增后，系统的线程池积压，导致大量请求超时。
2.2压测问题解决
针对上述问题，我梳理了一下自己的想法。
- 先观察线程池参数。确定线程池的大小
假设：一个thread_pool
core：64 max：128 queue：128
那我们可以通过上图进行qps的计算
-
通过 方法的本地调用时间 计算 qps
- RT上涨前：大约65ms QPS：1000ms/65ms ✖️ 64(核心线程数) ：大概1000qps
- RT上涨后：大约650ms QPS：1000ms/650ms ✖️ 64(核心线程数) ：大概100qps
-
进行线程池的分析
假设rpc超时是300ms，线程超时是500ms，案例图如下：
当那些已经在队列等待时长已经大于200ms的请求，其实执行成功的可能性已经不大，所以可能导致大量请求在队列积压。
当然具体问题具体分析，上述问题，还是要根据压测后积压的请求数、以及rpc成功率等为参考，重新规划系统的线程池。
三、心得
全链路压测是对大促前系统的一个检查，也是对系统稳定性的一个考验。压测后及时处理自己系统的问题，对突发情况进行再次的检查。以确保日后线上更好的应对流量激增。
本文是自己的一些心得分享，若有不对，请指正。
