谈谈压测方案的那点事 | 京东物流技术团队

原创
2023/11/10 09:58
阅读数 327

前言

在现阶段大促备战的压测不算是一件新鲜事,已经不存在什么技术瓶颈或者资源问题,每个团队都有很多人能够执行性能测试,在一些团队也已经落地了日常常态化,但压测也没有简单到只在压测平台上设置参数、运行脚本,然后去看压测报告中某个指标是否满足压测目标那么简单,我平时也跟一些同学一起做过性能测试,发现在压测过程中存在一些细节问题,有些同学做但不是很理解,压测方案对于性能测试来说是尤为重要一环,今天把对于压测方案方面的一些理解跟大家一起探讨一下;

性能测试的本质是模拟生产环境的用户,构造用户真实的行为请求,对尽量真实的压测系统施加压力,验证系统性能是否满足业务需要,是否存在性能瓶颈;

从里面可以看出核心的几个点:压测目标、压测场景、压测环境,今天主要从三大块来说

一、压测目标

我们在制定压测方案去说起压测目标的时候,很多同学都直接的考虑到TPS、QPS、TP99这些,

忽略了很重要的一项内容就是压测背景,就是因为什么原因我们要做这次压测,压测背景是我们压测的的方向,如果方向错了就会导致我们费时费力压测完成之后,压测的结论是没有意义的

那么压测背景和压测目标的关系是啥呢?

说一下我们现在常见的几种压测背景:

1、大促期间调用量对比平常明显有增长的业务

目标:是否能够支承大促预估峰值流量(业务预估+业务增长+大促增长)+单机房承载量+ 接口能支撑多大的调用量

结论:xxx配置最优/最大吞吐量xxx,能够支撑本次大促预估峰值调用量xxxx,是否存在风险;

2、上次大促压测过,但是之后新增/修改过的内容

目标:接口性能是否有变化+是否能够支撑大促预估峰值流量+接口能支撑多大的调用量

3、新增的接口,没有压测过,有业务预估调用量

目标:接口是否能够满足业务预估调用量(极限)+ 正常

4、新增的接口,没有压测过,没有业务预估调用量

目标:接口性能评估,系统性能是否存在瓶颈?有无优化空间?

5、新增的接口替换老接口

目标:接口性能评估,是否能够满足老接口的业务调用量+新增业务调用量

6、老接口的性能优化

目标:对比优化前优化后的性能指标,是否有优化效果

7、大促期间峰值调用量相比日常调用量没有明显变化,但是高峰时间拉长的业务

目标:峰值流量稳定性压测

8、没有太大的调用量,但是用户对于用户体验要求比较高

目标:接口响应时间是否有感官上的延迟,关注TP99,是否需要优化

9、不知道系统是否需要扩容

目标:极限压测,应用服务器和数据库资源使用情况是否合理

10、已知链路、接口性能比较慢,我需要知道瓶颈在那里

目标:找到链路、接口体系上的薄弱点(可优化内容)

二、压测场景

业务模型的调研和构建是我们压测前期工作中最为核心的一个环节,业务模型的创建要以实际生产环境系统业务操作模式为依据,只有模型符合实际的生产业务使用模式,性能测试的结果才能真实有效的反应上线后系统的性能情况,业务建模好坏直接决定性能测试执行的成功与否,也就是我们所说的压测模型

业务建模的过程中要分析清楚三件事情:

1、产生流量场景有哪些?如何选择需要压测的场景?

2、各场景和交易之间流量如何分配和设计?

3、要达成测试目标需要构造铺地数据需要多大的量,这些铺地数据该如何分配和部署;另外需要业务模型设计数据,数据要如何分配和构造

其实要做的就是在了解清楚业务并在其基础上完成:业务模型、流量模型及数据模型。

1、业务模型

一般从业务运营视角、技术运营视角、线上问题分析以及测试经验四个维度进行收集、整理和提炼:

业务运营:从实际业务应用的角度收集用户实际的使用情况和业务增长的趋势,比如我们有几个业务调用来源,平时用户使用最多的场景是那些,用户操作的高峰时段是什么时候?

技术运营:从技术运营角度去梳理我们接口实现逻辑的调用链路,比如说调度工作台线路展开查询,线路下任务低于20条的会去调异常接口,高于20条的不调异常接口;比如说查询接口实现的方式,走缓存还是走数据库;

线上问题:根据用户反馈和线上问题的收集,结合线上问题修复的方式;比如说一线反馈xxx操作会感知响应比较慢,研发在优化这个的时候会覆盖哪些用户操作场景

测试经验:根据测试经验来完善业务模型

2、流量模型

在业务场景确定后,就要思考各个场景和交易之间流量如何分配?。

生产环境的用户操作场景比较复杂的,请求报文的大小和请求路径也各不一样,使用单一的请求报文进行压测是不合理的,在流量模型分析的过程中有两种思考方式。即用户行为模型和系统业务模型。

用户行为模型:通过描述高峰时期用户行为特点,通过对用户行为调研分析,归纳总结出用户行为模型。比较常见的就是现在的流量录制,在业务高峰时间录制业务流量,然后进行流量回放,优点是实现起来比较简单,缺点是录制的流量用户行为较难统计分析。

系统业务模型:根据高峰时期系统业务特点,通过系统日志、数据埋点等方式获取高峰时段系统业务流量,获悉用户的主要流量行为,然后通过自己编写脚本和配置流量占比的方式来实现,优点是用户的流量占比比较清晰,缺点是要有数据的人工归类分析过程

3、数据模型

设计完成业务模型和流量模型,还要清楚需要多少基础数据(也叫铺地数据),铺底数据目的是测试时尽可能的与线上保持一致(至少数量分布一致),不管是哪类数据库,对于不同体量的数据,所走的查询器选择都是不一样的。几百行的数据走全表扫描肯定比走索引要好,但如果是几百万行呢?这方便需要我们具体地做评估。一般来说数据量要按照实际生产环境的数据量为多少为基础,在性能测试环境做等量代换。

总结:多少用户(WHO)在什么时间或者持续多长多久(When),在多大的数据量的基础上(How much),完成了什么业务(What),最终需要关注怎样的指标(How)。

举例:

单接口压测(调用方式不同):

1、默认页面打开自动查询,查询每页默认20条记录,也是最大的用户形式

2、通过接口调用,接口每页最大返回条数是1000条

单接口缓存压测:

  • 走缓存 10分钟
  • 不走缓存 10分钟
  • 部分命中缓存,部分未命中缓存,10分钟经历5分钟缓存失效

单接口混合场景压测:

调度工作台-分页查询用户权限内线路,不同的用户行为

1、1天1个区域查询量

2、1天7个区域查询量

3、混合场景(7天1个区域10%,1天7个区域20%,1天1个区域70%)三种

单应用多接口混合压测:

根据调用量进行接口调用配比

单业务接口混合压测:

适用场景:

运营指标看板(链路大屏页面,常用用户大概在150人左右),在用户访问大屏的同时调用五个接口方法:

用户初始进入页面后,默认无查询条件调用5个接口

用户在此页面停留,每隔30s自动刷新页面内容调用5个接口

用户手动录入查询条件,点击查询自动执行查询操作调用5个接口

极限压测:

【618备战压测-执行核心流程极限压测】测试方案

双实例线性增长验证

全链路压测:

【备战618性能测试-运输ORC接单】性能测试报告

系统稳定性压测

满足业务需求后,持续加压一段时间(4-6)验证系统稳定性

三、压测环境

1、优先考虑线上环境

2、压测环境与生产环境吞吐量差异,单实例压测和双实例压测怎么选择

3、压测环境与生产环境差异

4、铺底数据量压测环境与生产环境差异

作者:京东物流 朱飞

来源:京东云开发者社区 自猿其说Tech 转载请注明来源

 

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部