本文首发于博客:https://zingphoy.github.io/2020/04/26/服务端压测怎么做
博文的内容并不都是我原创的,行文思路来源于一次内部分享,再结合网上众多参考资料总结出来的,算是一个学习笔记。
可能很多QA、RD同学跟我都一样,对服务端压测一直没有系统的认知,印象停留在使用压测工具如Jmeter对单接口发压,调整线程数和循环数来制造不同压力,最后计算一下TPS和成功率等就完事了?网上虽然有不少压测相关的文章,但多数是压测工具的入门级使用,有的是压测流程和指标的简单解释,或者就是几个大厂牛逼的全链路压测能力和压测平台的介绍。这些文章要不缺少系统性阐述,要不过于抽象不好理解,对没怎么接触过压测的同学不太友好。
本文尝试在QA角度梳理一次完整的压测过程,尝试总结更为普适的压测思路,给大家提供更有意义的参考。
测试分很多种,网上很多文章1会玩弄概念,搬出来3个名词:压力测试(Stress Testing)、性能测试(Performance Testing)、负载测试(Load Testing)。一般情况下并不需要做这么细粒度的概念区分,这3个概念我觉得是没办法完整区分各自边界的,至少在程序逻辑上难以做得到,更多差异只是来自于不同的压测策略,所以尽管忽略这几个概念的区别,都叫它压测或者性能测试即可。
拿技术人熟知的阿里举例,应该是国内做压测最好的一个大厂。外界熟知的阿里2012双11活动,2012年11月11日零点,阿里各种系统报错、立刻下单报错、购物车支付报错、支付系统报错、购物车的东西丢失,系统显示交易成功率不到50%,产生了大量超卖,给阿里带来很大的损失。那一年的双11后,库存、商品、退款和相应数据库的同学,为了处理超卖导致的问题,没日没夜加了两周的班,同时给了用户不少糟糕购物体验。
为什么出现这么严重的问题?因为对整个全交易链路上的各个子系统的承受能力不清楚,并且错误预估了可能会达到的流量,也没有完善的预案,兵败如山倒。
2013年阿里首次提出了全链路压测方案:一方面可让链路的各个系统知道自己的承压极限;另一方面可让各个系统有个明确的优化目标,了解到整个链路的瓶颈并评估资源情况。
为什么只做单系统压测还不够呢?
在活动开始的瞬间,各系统都面临自身服务的巨大的压力,而系统之间是有互相依赖关系的,单机压测没有考虑到依赖环节压力都比较大的情况。一个系统出现故障,故障会在链路流转过程中层层累加,会造成无法评估的影响。
所以最可靠的方式是完全模拟真实场景来压测,通过线上全链路压测提前发现问题。
完整的压测流程一般包含下面几个步骤,引用自文末参考资料:
列举一些常用指标,并不一定都需要关注,根据业务考虑指标的细化粒度。
这里要说明一下QPS和TPS的区别:
性能测试中,平均值的作用是十分有限的,平均值代表前后各有50%的量,对于一个敏感的性能指标,我们取平均值到底意味着什么?是让50%的用户对响应时间hAppy,但是50%的用户感知到响应延迟?还是说50%的时间系统能保证稳定,而50%的时间系统则是一个不可控状态?
平均响应时间这种指标,只有在你每次请求的响应时间都是几乎一样的前提下才会有一样。再来个例子,人均财富这个概念有多沙雕相信大家也明白,19年有个很搞笑的新闻——腾讯员工平均月薪七万,明白平均值多不靠谱了吧。下图是现实世界中一个系统的响应时间柱状图,RT在前20%的请求数较少,但是因为耗时特别短(拉高了均值可能是命中缓存,也可能是请求的快速失败),而大多数RT是在均值之下,那才是系统的实际性能情况。
所以说,我们不应看最好的结果,相反地,应该控制最坏的结果,用户用得爽他不保证会传播好口碑,但是用户用到生气他保证变为键盘侠肆意大骂,这也是为什么平均值无法带来足够的参考,因为happy的结果蒙蔽了我们的双眼,平均值在压测中丢失太多信息量。
总结一下,较为科学的评估方法应该将指标-成功率-流量三者挂钩在一起的:
xx%的响应在xx毫秒内返回,其中成功率为xx%。
根据这个方针,可以得到一些测试思路:
压测开展前是需要有目标的,也就是有期望的性能情况,希望接口或系统能达到的性能预期,没有目的的压测是浪费人力,下面给出几种目标预估的方法。
已经上线并且有历史监控数据的接口,可以查看历史数据,找出峰值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如无特殊要求,一般采用默认值:
-1 电商秒杀活动,预估同时有1000w人参与,简单起见假设总QPS是1000w。由于前端不同的秒杀倒计时形式使得请求有2s的打散,再加上Nginx等webserver做了20%几率拒绝请求的策略,所以下单接口总QPS = 1000w / 2 * (1 - 0.2) = 400w/s,最终压测目标为400w/s的QPS。
-2 电商全天低价抢购活动,屠龙宝刀,点击就送,一刀99级,emmmmm跑题了。根据8/2原则,预估在午休(12-1)和晚上下班后(7-10)共4h是流量高峰,估算接口峰值QPS = 活动全天接口PV / (4*3600s)。
除了前面说到的情况,肯定还有一些我们无法下手的三无接口,无参考、无预估、无历史数据,这时候只能一点一点来,慢慢把压力提上去的同时收集数据,最终得出接口的最优处理能力。
压测是有目的的压测,也就是说不是随便找些接口发一通压力,而压测全部的接口也是做不到的或者说无意义的,得有压测的优先级,所以梳理压测场景是很重要的。高优场景主要有下面几个:
压测有分单接口压测和场景化压测,前者会简单一些,后者一般是多个接口混合操作以组成一个业务场景,两者在方法上是相通的。
梳理场景时QA需要与RD对齐,确认不同接口的RD负责人、需要压测的接口、系统性能现状以及压测目标;在确定每个接口的压测目标时,要考虑到压测对象是单实例单机房还是集群;在细节上也要确认是单接口压测还是场景化压测,每个接口的流量占比以及优先级,需不需要发足够的压力来触发系统的自动扩容或降级等更进一步的运维能力。
在梳理完压测场景后,就要确认压测链路是否完整或符合预期。从一个服务到另一个服务,是不是链路上每一个服务都要压到?下游服务如审计安全等是不是已经考虑到?压测过程中产生的脏数据是否会影响线上数据?可能还要细化到具体下游某个服务不参与压测,如何处理呢?以上种种问题,可能需要推动整个链路相关的业务方进行对应业务改造来适配压测流量,改造完后还要自测验证才能正式开始压测,下面讲一些重点问题,部分内容引用自文末的参考资料。
脏数据问题
不参与压测的服务如何处理
可以独立部署一套线下环境进行压测。在不影响线上环境的前提下,确保机房,网络,存储,上下游服务与线上保持一致,部署一套独立的环境进行测试,机器与线上隔离,机器出问题不会影响线上。这种方式压测只是针对较少的几个系统进行,因为很难把整个链路所有系统都独立再部署一套,所以应用范围有限。
备注:上游、下游如何定义? RFC 2616
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线上数据用来压测是很常见的手段,有两种简单思路:
数据dump下来是不能直接用的,一来没加压测标记会污染线上数据,二来涉及用户隐私数据。可以将线上数据作为数据源,经过采集、过滤、脱敏等操作后转变为压测数据,注意点有:
基本思路跟做质量保障是一样的,从细粒度开始慢慢集成到整个大系统,就像单测->接口测试->集成测试,压测也是先从简单的开始,一步一步走向全资源全链路,可以参考过程:单接口单机->单接口1/4资源->场景化1/4资源->全量资源压测->拨测。
在单核(或物理资源少)机器上部署单个服务,排除外部链路、网络等因素,得出自身服务的单核性能情况(单位QPS/core),后续根据此单核性能指标结合压测目标值进行扩容。另外由于是压的单接口单机,无其他接口请求影响,上下游在足够资源的情况下也不会造成瓶颈,所以能确保服务的性能真实值。
单接口单机可以在正式开始大规模压测前提前发现问题,方便RD做针对的性能优化并快速检验优化效果。一部分问题会先在单接口单机压测环节中发现,而一些隐藏得更深的问题,需要延后到全链路大流量压测才能暴露。
单接口单机压测环节,服务端已经完成了部分性能优化,接下来可以进入单接口1/4资源压测,这样是为了验证在单接口单机压测中得到的单核性能数据,在扩容1/4资源下性能是否会线性增长,是否存在性能损耗以及定位损耗源。
单接口压测局限很明显,场景化压测由于引入了上下游服务的其他接口的因素,可以发现单接口压测无法发现的问题,更接近线上用户场景。
全部资源到位后,预估的线上压力是否能承受,这一步也是内网压测过程的最后一步。
除了做内网压测,还要进行拨测验证用户从客户端到服务端的整个带宽资源是否满足预期,内网压测已经确认了业务性能是否达标,因此拨测可以只选择了一个场景进行验证即可。(简单来说拨测相当于压测cdn,检查各地cdn节点资源是否充足)
压测过程也要提前规划好,然后加入一定的人工策略调整。阿里大促还会有预热环节,预先跑一部分流量使得该缓存的数据提前缓存起来。正式压测时细分有几种压测策略,引用自文末参考资料:
除了关注前面讲到的指标外,还需要关注各机房流量是否均匀(若不均匀要确认负载均衡是否work)。
发压环节的结束并不代表压测就到此为止。
如果使用了影子表,可能收尾工作会简单一些,只需要下掉影子表即可。如果数据直接落到了线上数据库,可能一大堆压测数据要清理,压测时会对数据染色(比如指定测试账号或流量携带压测标记),逐层透传,最后根据标志识别删除。
举例一些可能会发现的典型问题:
……
给出一个完整的压测过程例子:
压测最终应该输出一份报告总结,其实也就是把整个压测方案、过程、结论记录下来,写明压测目标、压测接口、压测数据、压测结论,给出发现的问题并提供优化方案。往往在压测报告完成时,性能问题已经基本被解决了,报告的意义在于梳理前面的整个流程,给后续的压测提供经验指导。
[1] https://www.guru99.com/performance-vs-load-vs-stress-testing.html
[2] https://www.toolsou.com/en/article/200293789
Why Averages Suck and Percentiles are Great
CoolShell-性能测试怎么做
全链路压测的大概思路
独家揭秘 | 阿里怎么做双11全链路压测?
亲历流量尖峰时刻:一名阿里技术员工的双11十年
What is Upstream and Downstream in Software Development?
一个阿里技术男经历的六年“双11”:技术改变阿里