全链路压测分析

原创来源于软件测试架构师俱乐部,作者cctester

最近网传,微信支付崩了,哈罗出了问题,部分公司性能测试架构师招聘又开始火热起来,现在都叫做全链路压测,那什么是全链路压测呢,跟传统压测区别是啥呢?全链路最早是阿里提出来的,在2012年的双11,零点的时候,系统交易成功率不足50%,下单报错,购物车报错,并伴随着大量超卖,后来提出了全链路压测,这篇文章就来聊聊全链路压测的关键点。

面试过很多公司,性能测试有很多形态,一般的公司还在工具使用阶段,做下简单的监控,然后出报告,结束,这样的做法基本就是走个形式,也有的开发团队相对负责,会在压测的过程中协助诊断,看看有没有优化点,一般来说多少会发现一些问题,会有些效果,但是往往大促,又会出现其他问题,leader问不是做过压测了吗?你觉得做过,但好像又做得不够.....

1.什么是线上全链路性能测试:

基于真实的用户场景,实际线上环境,按照既定流量,对各个业务链路进行压力测试的过程。

2.为什么要做全链路性能测试:

很多公司有线下性能测试,为啥还要做全链路呢,能解决一般性能测试的什么问题呢?我认为在每个环境做性能测试是相互补充的过程,在线下的性能测试,由于机器监控,部署迅速以及相应的权限充足,我们可以迅速定位到一些性能bug,如内存泄漏,死锁,超卖等问题,但是线下的机器达到的指标不能准确的反馈到线上的实际情况,我们并不能简单通过一些充满大量经验值的公式去推算,这样的结果和拍脑袋也没啥太大差异,再加上线下环境大多以分链路,模块压测为主,所以全链路压测在这样的背景下就诞生了,我们的前提是在线下已经模块压测完成,无明显瓶颈的情况下开展,在线上进行链路的充分模拟压测。

3.全链路压测的核心是什么?

无论何种测试,核心的东西一定是需求分析,那全链路性能需求分析的要点是啥呢,和传统线下性能测试有啥区别呢?

请求数据源:

在传统线下性能测试,一般我们拿到接口参数便开始调试,写脚本,按照场景进行测试,而线上我们需要根据实际数据源统计,包含web端,app端,小程序端等,这个是我们的客户端数据来源,还有我们的运营商带宽占用情况,cdn节点的分布,这样就涉及到外网的压测,外网的压测策略和内网细节上的差别还是比较大的,本文不作具体讨论。

架构拓扑分析:

线上的部署结构往往比我们测试环境要复杂很多,测试环境往往是线上很小的一个分支,线上各种微服务的依赖集群,中间件,db需要调研的非常清楚,多少服务器,服务器上部署实例的情况,每个细节都会影响到压测的结果,以及分析的准确性。

数据分析:

数据分析可以分很多层次,在一般的性能压测中,我们一般会关注参数化数据和db数据,全链路压测中,还需要关注,redis数据,mq堆积,以及key的大小对实际带宽的影响,这些都跟中间件相关,一旦出现问题,对网站的影响往往是毁灭性的,带宽这块往往也是线下局域网测试不能覆盖的,线上会跨机房调用,所以尤其需要关注这块。

监控分析:

大多是情况下,我们会做硬件层的监控包括cpu,带宽,内存,磁盘等,然后客户端进行数据采集,指标一般也通过压测数据采集,但这些在全链路压测中还是显得还有基础,我们需要去通过更多服务器维度监控,包含各服务集群的业务指标数据,db层的实时下单数据,容器级别资源监控数据等内容,以及结合健康度指标等,在线上压测需要设置阈值,尽可能规避线上风险,防止造成用户流失。

压测目标的设定:

我们很多公司在线下压测的时候因无参考数据,可能压到拐点作为首选目标,而成熟的互联网公司一定会做线上的容量评估,一般会根据以往业绩以及流量相结合,会有一定比例增长的预估,还有通过推送转化率去评估,个人觉得可以长期做模型去进行数据积累,达到经验值的参考。

流量回放:

首先来说,能做到流量回放的公司很少,这个涉及到系统的改造,关键在于数据加工这块,能达到流量回放,测试的很多前期准备工作会少很多,但同时前期的开发改造任务也非常繁重,在阿里也一个开发团队封闭改造三个月才有一个雏形版本,任何一家公司都可以引用一种技术类型,但是做的深浅会很不一样。

本文分享自微信公众号 - 工程师的自我修养之路(Engineer_Way)

原文出处及转载信息见文内详细说明,如有侵权,请联系 [email protected] 删除。

猜你喜欢

转载自www.cnblogs.com/hellolonewoif/p/12168416.html