压测
压测的目的
- 新服务，无预估目标，需要通过压测得到服务基准数据或找到系统瓶颈进行优化
- 有明确的压测目标，需要通过压测确定服务的各项指标是否达标
- 常态化压测，为后期性能优化指导方向或提供参考依据
压测关注的常用指标
备注：并不一定都需要关注，根据业务考虑指标的细化粒度
- QPS：Query Per Second，每秒处理的请求个数
- TPS：Transactions Per Second，每秒处理的事务数，TPS <= QPS
- RT： Response Time，响应时间，等价于Latency RT分平均延时，Pct延时（Percentile分位数）。平均值不能反映服务真实响应延时，实际压测中一般参考Pct90，Pct99等指标
- CPU使用率：出于节点宕机后负载均衡的考虑，一般 CPU使用率 < 75% 比较合适
- 内存使用率：内存占用情况，一般观察内存是否有尖刺或泄露
- Load指标：CPU的负载，不是指CPU的使用率，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，表示CPU的负载情况，一般情况下 Load < CPU的核数*2
- 缓存命中率：多少流量能命中缓存层（redis、memcached等）
- 数据库耗时：数据库就是业务的生命，很多时候业务崩掉是因为数据库挂了
- 网络带宽：带宽是否瓶颈
- 接口响应错误率 or 错误日志量
QPS和TPS的区别：
- QPS一般是指一台服务器每秒能够响应的查询次数，或者抽象理解成每秒能应对多少网络流量
- TPS是指一个完整事务，一个事务可能包含一系列的请求过程。举个例子，访问一个网页，这是一个TPS，但是访问一个网页可能会对多个服务器发起多次请求，包括文本、js、图片等，这些请求会当做多次QPS计算在内，因为它们都是流量。
压测目标预估
压测开展前是需要有目标的，也就是有期望的性能情况，希望接口或系统能达到的性能预期。
常见的预估方法
-
历史监控数据
已经上线并且有历史监控数据的接口，可以查看历史数据，找出峰值QPS和PCT99。举个栗子，若接口A已经上线并且做了监控，在经过某次大活动或者上线时间足够长后，存量监控数据就可以使用了。
-
类比
新接口或者线上未监控的接口，不存在历史数据，但存在类似功能接口的历史监控数据，可以通过类比得出压测的目标。举个栗子 假设上一年淘宝双十一下订单接口QPS=x，RT=y，这一年天猫平台整起来了，双十一活动与上年淘宝双十一活动场景类似，也沿用QPS=x，RT=y的目标（例子不严谨，理解即可）。
-
估算
新接口或者线上未监控的接口，不存在历史数据，且不存在类似功能接口的数据可供参数考，此时需要估算峰值，常用方法有8/2原则——一天内80%的请求会在20%的时间内到达。
top QPS = (总PV * 0.8) / (60 * 60 * 24 * 0.2)
RT如无特殊要求，一般采用默认值：
- 单服务单表类，RT<100ms
- 较复杂接口，RT<300ms
- 大数据量或调用链较长的接口，RT<1s
例子1： 电商秒杀活动，预估同时有1000w人参与，简单起见假设总QPS是1000w。由于前端不同的秒杀倒计时形式使得请求有2s的打散，再加上nginx等webserver做了20%几率拒绝请求的策略，所以下单接口总QPS = 1000w / 2 * (1 - 0.2) = 400w/s，最终压测目标为400w/s的QPS。
例子2： 电商全天低价抢购活动。根据8/2原则，预估在午休（12-1）和晚上下班后（7-10）共4h是流量高峰，估算接口峰值QPS = 活动全天接口PV / (4*3600s)。
-
其他
除了前面说到的情况，肯定还有一些我们无法下手的三无接口，无参考、无预估、无历史数据，这时候只能一点一点来，慢慢把压力提上去的同时收集数据，最终得出接口的最优处理能力。
压测准备
压测场景
压测是有目的的压测，也就是说不是随便找些接口发一通压力，而压测全部的接口也是做不到的或者说无意义的，得有压测的优先级，所以梳理压测场景是很重要的。高优场景主要有下面几个：
- 高频业务场景
- 关键业务场景，使用频率低，一旦出问题就很严重
- 性能高消耗场景
- 曾经出现过问题的场景
压测有分单接口压测和场景化压测，前者会简单一些，后者一般是多个接口混合操作以组成一个业务场景，两者在方法上是相通的。 梳理场景时QA需要与RD对齐，确认不同接口的RD负责人、需要压测的接口、系统性能现状以及压测目标；在确定每个接口的压测目标时，要考虑到压测对象是单实例单机房还是集群；在细节上也要确认是单接口压测还是场景化压测，每个接口的流量占比以及优先级，需不需要发足够的压力来触发系统的自动扩容或降级等更进一步的运维能力。
压测环境
在梳理完压测场景后，就要确认压测链路是否完整或符合预期。从一个服务到另一个服务，是不是链路上每一个服务都要压到？下游服务如审计安全等是不是已经考虑到？压测过程中产生的脏数据是否会影响线上数据？可能还要细化到具体下游某个服务不参与压测，如何处理呢？以上种种问题，可能需要推动整个链路相关的业务方进行对应业务改造来适配压测流量，改造完后还要自测验证才能正式开始压测，
下面讲一些重点问题（引用网络资料）
脏数据问题
- 如果是在独立的一套环境中操作，不存在该问题
- 影子表：线上压测一般将数据写入影子表（在schema上与原数据表一致的不同名表，如user表对应影子表user_stress）而非原数据表，实现压测数据与线上数据隔离
- 白名单：指定测试id或者测试账号，在入库后通过统一id区分压测数据，统一处理
- 各类存储层的压测改造，包括缓存层、消息队列、离线数据库等隔离问题。常规方法在压测链路中透传压测标记（也叫流量染色，挺形象的），比如json数据中加
is_stress标记，存储层根据标记区分压测流量，对压测数据添加指定前后缀再入库等特殊处理
不参与压测的服务如何处理
- mock server：mock服务返回响应的时长应该遵循线上时延分布，对业务的代码实现无侵入
- 服务stub：针对压测流量做处理，类似单测stub，代码stub模拟服务返回response，需要修改代码
可以独立部署一套线下环境进行压测。在不影响线上环境的前提下，确保机房，网络，存储，上下游服务与线上保持一致，部署一套独立的环境进行测试，机器与线上隔离，机器出问题不会影响线上。这种方式压测只是针对较少的几个系统进行，因为很难把整个链路所有系统都独立再部署一套，所以应用范围有限。
备注：上游、下游如何定义？
Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream.
下游的输入来自于上游的输出，假设有服务A、B，A调用了B（或者说A依赖B），那B就是A的上游，A就是B的下游，因为A的输入来自于B的输出（A调用了B，获取B的输出）。
更简单地理解，越接近用户的东西，越是下游。
更常见的方法是直接使用线上环境压测，在机器负载低的时间段（如深夜）人工发起或定时发起压测。
压测监控体系
确认好压测流程的技术支持和Mock数据的支持后，还要确认压测链路的监控体系是否完整，一来方便在压测过程中及时发现问题，二来是为了积攒历史压测数据，三来顺便确认监控系统本身是否可靠且全部到位。一般监控项包括（也就是压测指标）：
- 核心接口和核心依赖的流量、响应耗时、成功率
- 消息队列、缓存、数据库
- 机器物理资源
压测数据
压测数据其实没什么神秘的，网上说什么按照业务模型产出数据，表达上做了过度抽象反而不好理解，其实意思就是按照业务核心场景将所需要的数据构造出来。关键是要如何科学地模拟线上数据分布，阿里双十一大促中有如下的业务流量漏斗模型，需要给不同场景科学地分配流量比例，这个比例是分析出来的而不是拍脑袋的。可以想象，阿里大促的流量不可能全部最后都走到付款流程，必然很多流量会在前面的流程就结束了，也就意味着，你把全部压测数据都构造成【走到付款场景】的话，你的压测结果是不准确的。
为了更好模拟线上真实的用户使用场景和数据，dump线上数据用来压测是很常见的手段，有两种简单思路：
- 直接回放提前录制的线上流量到压测链路
- 将现成流量copy一部分引流到压测链路
数据dump下来是不能直接用的，一来没加压测标记会污染线上数据，二来涉及用户隐私数据。可以将线上数据作为数据源，经过采集、过滤、脱敏等操作后转变为压测数据，注意点有：
- 确保数据已添加压测标记
- 账户数据要提前完成登录认证等准备工作
- 数据要尽可能跟真实数据保持一致，比如，价格，图片等
- 数据是否有不同设备型号等特殊要求
- 尽量保持和线上相同缓存的命中率
- 其他业务特性上的特殊要求……
压测过程
基本思路跟做质量保障是一样的，从细粒度开始慢慢集成到整个大系统，就像单测->接口测试->集成测试，压测也是先从简单的开始，一步一步走向全资源全链路，可以参考过程：单接口单机->单接口1/4资源->场景化1/4资源->全量资源压测->拨测。
单接口单机
在单核（或物理资源少）机器上部署单个服务，排除外部链路、网络等因素，得出自身服务的单核性能情况（单位QPS/core），后续根据此单核性能指标结合压测目标值进行扩容。另外由于是压的单接口单机，无其他接口请求影响，上下游在足够资源的情况下也不会造成瓶颈，所以能确保服务的性能真实值。 单接口单机可以在正式开始大规模压测前提前发现问题，方便RD做针对的性能优化并快速检验优化效果。一部分问题会先在单接口单机压测环节中发现，而一些隐藏得更深的问题，需要延后到全链路大流量压测才能暴露。
单接口1/4资源
单接口单机压测环节，服务端已经完成了部分性能优化，接下来可以进入单接口1/4资源压测，这样是为了验证在单接口单机压测中得到的单核性能数据，在扩容1/4资源下性能是否会线性增长，是否存在性能损耗以及定位损耗源。
场景化1/4资源
单接口压测局限很明显，场景化压测由于引入了上下游服务的其他接口的因素，可以发现单接口压测无法发现的问题，更接近线上用户场景。
全量资源全链路
全部资源到位后，预估的线上压力是否能承受，这一步也是内网压测过程的最后一步。
拨测
除了做内网压测，还要进行拨测验证用户从客户端到服务端的整个带宽资源是否满足预期，内网压测已经确认了业务性能是否达标，因此拨测可以只选择了一个场景进行验证即可。（简单来说拨测相当于压测cdn，检查各地cdn节点资源是否充足）
压测策略
压测过程也要提前规划好，然后加入一定的人工策略调整。阿里大促还会有预热环节，预先跑一部分流量使得该缓存的数据提前缓存起来。正式压测时细分有几种压测策略
- 峰值脉冲：流量是逐渐变大的一个小坡，还是骤升后保持高峰
- 系统摸高：关闭熔断降级限流等fallback功能，提高压力观察系统性能转折点
- fallback策略验证：开启熔断限流等fallback功能，这些功能是否生效，系统是否还能扛得住
- 破坏性测试：主要为了验证预案的有效性，类似于容灾演练时的预案执行演练，验证后手抢救方案
除了关注前面讲到的指标外，还需要关注各机房流量是否均匀（若不均匀要确认负载均衡是否work）。
压测收尾
发压环节的结束并不代表压测就到此为止。
数据清理
如果使用了影子表，可能收尾工作会简单一些，只需要下掉影子表即可。如果数据直接落到了线上数据库，可能一大堆压测数据要清理，压测时会对数据染色（比如指定测试账号或流量携带压测标记），逐层透传，最后根据标志识别删除。
常见问题
举例一些可能会发现的典型问题：
- 存在多余的http header，导致额外带宽占用
- spin_lock对RT影响大，优化锁的方式
- 调整nginx worker数量可提高性能
- 不恰当的长链接数
- 代码实现上对象没有较好复用
- cache命中率不符预期
- 业务流程上存在冗余
- 缺少一层cache
- 响应码or错误码可能要继续规范
- 下游服务资源不足（其他监控、存储）
- 内部系统对压测的限流，需要变更配置或者协商解除限制
……
压测总结
给出一个完整的压测过程例子：
- 确定本次的压测目标，预估各项指标的达标值
- 根据服务接口的优先级和使用场景，确认出需要压测的接口
- 梳理压测链路上的服务，确认链路完整性
- 针对压测链路设计的服务进行压测改造
- 准备压测数据，确认压测策略
- 开始压测，监控各项指标，多轮压测检验性能优化效果
- 压测环境清理
- 压测总结报告输出
压测最终应该输出一份报告总结，其实也就是把整个压测方案、过程、结论记录下来，写明压测目标、压测接口、压测数据、压测结论，给出发现的问题并提供优化方案。往往在压测报告完成时，性能问题已经基本被解决了，报告的意义在于梳理前面的整个流程，给后续的压测提供经验指导。
