性能实战之容量场景设计
2022-12-19 13:56 第二个卿老师 阅读(223) 评论(0) 编辑 收藏 举报之前文章说过补一篇容量场景设计,虽然看过很多文章,但自己实现起来却很费劲。
容量场景
什么是容量场景?
容量场景指所有业务通过一定比例混合的场景,也是代表真实的用户级场景。
什么是业务模型?
真实的用户场景也就是生产业务场景,而把生产业务场景通过建模方式得到的模型就是业务模型。
于是,业务模型决定了容量场景的有效性。那怎么得到这个业务模型?
高楼老师提到,首先得明确当前场景是要模拟历史业务场景,还是未来业务场景。未来业务场景需要业务团队给出评估,而历史业务场景最好要有历史业务数据支撑。
我这里是模拟历史业务场景,所以第一轮性能测试没有做容量测试,这次是有了线上运营数据后,我才开始的做的容量测试。
业务模型分析
现在历史数据有了,我们可以按照以下步骤来得到业务模型。
统计生产业务量
我们没有ELK这种顺手的日志统计系统,但能从nginx访问日志中抽取。
由于我们主要流量是虚拟商品售卖业务,日常流量不大,通过命令查看售卖当天业务分布情况,如下命令
cat xxxx.log|awk '{print $4}' |cut -c 2-18|uniq -c # $4是指以空格分割的第4个元素,根据实际nginx日志格式来,修改cut -c部分可以按时、分、秒来统计
统计峰值TPS的业务场景
通过上述命令,得到当天10-11点为峰值流量(也能对应售卖时间),但由于日志中接口路径存在多种格式,使用命令无法完全过滤,写了个python分析脚本,结果如下:
当天流量情况
峰值10-11点情况
通过上图可知:
- 10-11点峰值流量几乎占当天流量的一半,而且各业务流量分布基本一致,即用该业务模型做一个容量场景即可。
- 得出了每个请求的请求数占总数的比例,存在一些少量请求的接口(0.1%以下)。
- 接口中存在调用第三方的接口,比如支付宝、微信支付。
由于jmeter中吞吐量控制器的百分比单位最小保留一位,即0.01%是设置不了的。所以要么过滤掉,要么一起合并。
严格来说,可以合并到一个事务,然后比例选择执行,但考虑到样本太少,我当时这里是过滤掉的,如下图:
于是我们得到了各接口比例,而部分接口涉及第三方,可以做mock,也可以改造代码,由于我这边返回的是支付二维码,跟实际支付无直接关联,就正常调用就行。
梳理业务流程
各接口的比例已经出来了,那么为什么要梳理业务流程呢?因为容量场景需要模拟线上业务场景。
而我们的主要业务流程就是:登录>查询商品列表>查询商品详情>选择商品下单>提交订单支付。
然后把各业务对应的请求列出来(做基准测试时就应该理出来),比如下单就包括两个接口,部分如下表
这里就需要考虑业务脚本设计方式了,包括两种:一是直接按照接口比例设计脚本;二是按照业务比例设计脚本。
第一种接口比例:
合并同比例接口作为一个事务,这样可能需要额外造测试数据。比如A接口与B接口的比例一致,可以放在一个事务中。如下图所示(相同比例分类):
第二种业务比例:
合并同业务流程的接口,这样不用额外造测试数据,但需要计算各接口在各业务中所占比例。比如A接口比例为30%,可能在业务1占15%,在业务2占15%,就分成了两个事务。如下表所示:
由于当前场景主业务单一,按照业务逻辑设计脚本,基本不用额外造测试数据,所以选择了较为简单的接口比例设计脚本。
于是把业务比例加入业务请求表中,得到了8个事务及其比例:
这是就得到了业务模型。
场景脚本实现
业务模型有了,现在我们来实现场景脚本,分为两部分。
实现业务脚本
业务脚本是个接口的比例,把基准测试的脚本拿过来改下即可,这里需要注意业务逻辑,做好业务上下文依赖数据的关联。
这些数据都是要提前准备的
实现业务比例
根据业务模型可以看出各事务的比例,我使用Jmeter的吞吐量控制器,还需要再计算一下(加入了TPS比例):
最后Jmeter场景脚本设计如下:
仔细看看貌似漏了那个39%的事务,由于这个接口是定时轮询支付结果接口,所以我把它放入了循环里面,包含了微信与支付宝下单。
总的TPS是3.1%,随机选择微信和支付宝支付,(23*1/2+2*1/2)*3.1%=38.75%,约等于39%,最后运行场景,结果如下:
验证下比例(1926+20316)/94012=0.2365,与25%相差不大,得出场景正确。